How to use CAUSE/CONTEXT in a non-event-driven pipeline?

[e-backmark-ericsson]

Description

It is not clear when reading the documentation how ActT events should be linked in a non-event-driven scenario.

Motivation

We need clear semantics in the way pipeline activities should be linked together in a non-event-driven scenario

Exemplification

A pipeline driven by e.g. Argo. How should the events be linked to each other? One way is to let the ActT of a pipeline step link to the previous ActF (or ActT?) by a CAUSE link, but maybe we should instead create a new link type for such a link?

Benefits

Clear semantics in an event graph describing the order of activities in a non-event-driven scenario, enabling clear visualizations and metrics.

Possible Drawbacks

None

[magnusbaeck]

A CAUSE link to a ActF event seems reasonable. That expresses that the second build starts because the first one was successful (typically) and that makes sense. I happened to draw the following a few days ago:

[e-backmark-ericsson]

I'm currently preparing a proposal for activity events. Here are two preliminary graphs for that.

[t-persson]

@e-backmark-ericsson Should the "CAUSE" link in the second image really be recommended? The CONTEXT already shows that this CD was produced in the activity "PIPELINE STEP 1". Reason for my question is because we have this description on CAUSE links:

"Description: Identifies a cause of the event occurring. SHOULD not be used in conjunction with CONTEXT: individual events providing CAUSE within a larger context gives rise to ambiguity. It is instead recommended to let the root event of the context declare CAUSE."

[magnusbaeck]

This was discussed at the 2021-09-16 community event workshop. Here's an attempt at a summary:

• CONTEXT links should be used when the source event is done as a part of the target event, i.e. it's a substep or subtask. In Emil's colorful example above the Step 1, ..., Step 4 activities should have a CONTEXT link to the Pipeline X activity.
• CAUSE links should be used when the target event is the cause of the source event. This could be true for Step 1 and Step 2, where Step 2 can be triggered because of Step 1's ActF. However, the CAUSE link shouldn't target Step 1's ActT.
• We see a need for another link type that conveys that two activities take place sequentially without any explicit causality. ANCESTOR and PREDECESSOR were floated as possible names.
• The end result would be that CONTEXT is used for horizontal/overlapping stacks of activities, CAUSE when there's a strict causality between events, and ANCESTOR/PREDECESSOR when activities have a non-causal relationship and take place sequentially.
• The current recommendation that CONTEXT and CAUSE shouldn't be used in the same source event should be removed or at least reworded. The purpose of the CAUSE event should be more clearly defined.

cc:
@e-backmark-ericsson
@k-hallen-ericsson
@m-linner-ericsson
@t-persson

[m-linner-ericsson]

Suggestion on the definition of PRECURSOR:

• A non-event triggered occasion can provide the PRECURSOR link in its event to describe order and parallelism
• CAUSE and PRECURSOR are mutually exclusive
• If both events have context link, they should be the same target event
  • E.g. Possibility to user PRECURSOR to link nightly builds
• Legal targets and sources: ActT, TSS, TCT
  • Target and source can be different types
  • All these have a start and end event (describes execution)

Example usage:

[magnusbaeck]

I think we're ready to complete the PR for this.

Apart from the definition above, should we state explicitly that the precursor activity (or test suite/case) may or may not have completed?

[e-backmark-ericsson]

I will update the PR