Generic vs. concrete activity events?

[erkist]

There is a discussion in #8 that I believe warrants a larger discussion as it will have impact outside of that specific scenario (for instance when we get to Continuous Delivery activities later on).

Do we want concrete activity events (Build, Test Queued/Started/Finished etc.) or generic activity events (Activity Queued/Started/Finished etc.)? Or some combination of the two?

There appear to be plenty of existing schemas that have gone either of the above ways, for instance Fedora has concrete events https://pagure.io/fedora-ci/messages/blob/master/f/schemas wheras Eiffel has generic events https://github.com/eiffel-community/eiffel/blob/master/eiffel-vocabulary/EiffelActivityStartedEvent.md

Regardless of which way we choose, I believe we will still need to show what type of activity the event concerns, so maybe the fundamental differentiating factor is: Should it be the event type or some attribute value that states what kind of activity is being run?

[salaboy]

@erkist maybe by having more concrete examples, we can simplify the discussion. For example, now in the CI PR we have the Tasks for the pipelines which can be considered in some way as generic events, I think that's a good compromise. If not we fall into the discussion of why is an Activity related to CI or CD? In my opinion, if we go too generic we are actually not defining much. So here are some questions that might help me to understand your point of view:

• Can you give examples of "type of activity the event concerns" ?
• Can you give examples of "some attribute value that states what kind of activity is being run"?

The event type is highlighting the activity that is being run, making explicit which kind of Activities the spec is interested in, by that reducing the mental overhead from adopters to understand what is a generic activity and when it needs to be used...

my two cents..

[erkist]

Can you give examples of "type of activity the event concerns" ?

Sure, here are examples of activity types from a CD flow for embedded systems:

1. Build and register component version
2. Create baseline
3. Prepare test environment
4. Install baseline
5. Run automated tests
6. Analyze and upload node logs
7. Run simulation
8. Analyze and upload simulator logs
9. Package for release

Can you give examples of "some attribute value that states what kind of activity is being run"?

Sure! Something like:

Optional attribute:
  **Activity Type**: The type of activity being run (e.g. "create_baseline", "prepare_test_environment" etc.)

For example, now in the CI PR we have the Tasks for the pipelines which can be considered in some way as generic events, I think that's a good compromise.

I would be fine with that, as long as it is possible to do things other than build and test, I am happy.

[afrittoli]

Thanks @erkist - this is a very good discussion to have. In my mind, generic events is what I call "orchestration" events, which are events at a higher level of abstraction, common to all kind of specific activities.

To make an example, a system may have a concept of workflow, or pipeline, or series of activities of some kind (the terminology varies). This workflow may include one or more activities, in series, in parallel or a combination.
Orchestration events would be about workflow queued, started, running, finished, and activity queued, started, running, finished.
A system may rely on an external orchestrator, so you may have orchestration events generated by one system and specific events generated by a different one.

You could have for instance the following sequence of events for a workflow that clones a repo and build binaries when a change is proposed:

• repository change opened
• workflow started
• activity started (cloning the repo from the change)
• activity finished
• activity started
• build started
• build finished
• activity finished
• workflow finished

[erkist]

I agree with all of that, I think! I like the concept of an activity that, as part its execution, invokes (and sends events for) a build. Or a test.

[e-backmark-ericsson]

One concern I have against just defining specific events for certain activities, and not having a generic activity event, is that there will always be activity types that are not covered by the types we define.
For example: if we define the following very short list of possible activity event types: "build", "test", "deliver", "deploy". Then if someone for example has a "FOSS scanning" step in his/her pipeline, what event type should be chosen? We would need to provide a 'other_activity_type' event type for such cases, as we will not be able to add new activity event types immediately to cater for everyones need. If we instead would have generic "activity" event types, we could include a mandatory parameter in those generic event types stating what kind of activity is it. That parameter should then be an Enum with some well defined values such as "build", "test", "deliver", "deploy" and "other". And that Enum should of course be updated in the protocol for any coming decent activity types we see suitable to define.

[m-linner-ericsson]

Should we then suggest a generic activity event?

[afrittoli]

Working Group Decision:

• We define a generic activity.
  • A generic activity defines common params required by all activities
  • This creates a hierarchy of events
• We define specific activities
  • Implementors SHOULD use a specific activity if available

---

For the JSON Payload binding we need to decide whether specific activities need to match the schema of the generic one - i.e. do we want to have a hierarchical structure between events.