Events

The OBS has a pub/sub event system built in. Events describe something that happened throughout the OBS (backend and frontend). Things like

• The build of package FOO in project BAR has failed
• The submit request #12345 was accepted
• A comment was created in project FOO

Events are published, subscribers express interest in certain events, subsystems then react to published events. For instance:

1. User henne subscribes for mails about events that concern packages where he is maintainer
2. An event that concerns the package, where henne is maintainer, is published
3. Based on the subscription a mail is sent to henne, containing details about the event

Types of Events:

See Event::Base and classes inheriting from it (e.g. Event::CommentForProject or Event::RequestStatechange).

Publishing Events

We publish an event by creating an instance of Event in the database. The code below will, for instance, create an event that describes that a the package obs-server was branched by the user henne.

Event::BranchCommand.create(project: 'OBS:Server:Unstable',
                            package: 'obs-server',
                            targetproject: 'home:henne',
                            targetpackage: 'obs-server',
                            user: 'henne')

Throughout the app Event instances get created by

1. code like above
2. the OBS backend

Most of the events happen in the OBS backend. It exposes them on its /lastnotifications API. We poll this API periodically (via clockwork) with the UpdateNotificationEvents class. That class then creates instances of Event in the database.

Subscribing to Events

We subscribe to an event by creating an instance of EventSubscription in the database. The code below will, for instance, create an email subscription for the user henne for all Event::BuildFail events, concerning packages henne is maintainer of.

EventSubscription.create(eventtype: "Event::BuildFail",
                         receiver_role: "maintainer",
                         user: User.find_by(login: 'henne'),
                         channel: "instant_email",
                         enabled: true)

Reacting to Events

There are several subsystems that react to the publishing of events.

Based on Subscriptions

• NotificationService is creating web notifications and RSS feeds for users.
• EventMailer is sending emails to users.

Both are triggered by SendEventEmailsJob which is scheduled periodically by clockwork.

Without a Subscription

There are several other things that react to events.

• CreateProjectLogEntryJob is filling the ProjectLog with entries. This job is scheduled by many of the events.
• UpdateBackendInfosJob keeps The-BackendPackage-Cache fresh. This job is scheduled by commit and service events.
• UpdateReleasedBinariesJob tracks published packages. This job is scheduled by packtrack events.

Publishing Events to the Message Bus

Many events are also published on the RabbitMQ message bus when they happen.

Event classes that respond to the the message_bus_routing_key method are send to the obs exchange. Event classes that respond to the method metric_fields are send to the metrics exchange.

Cleaning up Events

The CleanupEvents job destroys all the Event instances where the other subs-systems have done their job. This state is tracked in the Event instance.

Jobs that inherit from CreateJob increase the Event.undone_jobs attribute by 1 if they are scheduled. And subtract Event.undone_jobs attribute by 1 if they are finished. SendEventEmailsJob sets Event.mails_sent to true once it finishes.