Better linking from ActT to SCC/SCS

[e-backmark-ericsson]

Description

Imagine an activity that is triggered based on an SCM commit or merge. An ActT event is sent with CAUSE set to that SCC or SCS event and triggers.type set to EIFFEL_EVENT. Then if that activity was retriggered manually resulting another AcT event being sent the ActT would have triggers.type set to MANUAL. But how should the previously sent SCC/SCS event be linked? Linking it with CAUSE does not feel right. Another link type should probably be added there, or?

Motivation

Make the links to SCC/SCS events from ActT events more elaborated

Exemplification

As described in description

Benefits

See above

Possible Drawbacks

None

[t-persson]

Are we talking another link type specific to SCC/SCS? That is very specific if that is the case.

Why doesn't a CAUSE link feel right in this case?

Would a link type "RETRIGGERED" which points to the original ActT solve this problem?
You would have to dig a bit more in the event repository, but it might be worth it.
Maybe add a similar link type to the TCT if one is added here.

[e-backmark-ericsson]

Thanks for commenting Tobias. The CAUSE link is meant to point out the cause of an event occurring. In this case the cause is actually a manual decision saying that we need to rerun this activity. It could of course also be a machine identifying that an activity should be retriggered. So the cause is not the SCC/SCS itself. I agree that it could be strange to mention a specific type of event here. And there could be multiple similar CAUSE links to other events from ActT that should be replaced by something more specific. I'm not sure what road to take here. This issue is also somehow related to #227.
Having a RETRIGGERED link type is actually an interesting alternative, which could be applied to several event types. Let's dive into that suggestion a bit further to see if it holds.

[magnusbaeck]

I think a new link type for retriggering is a good option. Copying the CAUSE links of the original ActT would be a lie, but linking to the original ActT conveys that it's a retrigger and provides a path to the original cause(s).

(I wonder if a present tense link name like RETRIGGER or RETRIGGERS would be preferable over RETRIGGERED.)

[magnusbaeck]

This discussion seems to have stalled. Does that mean we're ready to move on to a PR? I was reminded of this when looking into how the Jenkins plugin I'm working on behaves when existing builds are rebuilt.

Having a RETRIGGERED link type is actually an interesting alternative, which could be applied to several event types.

Definitely TestCaseTriggered, but did you have any other in mind?

[t-persson]

I like the idea of having a RETRIGGER link type and that name is better, in my opinion.
Another event that it could be added to could be TestSuiteStarted? We work a lot with test suites and I think it would fit ETOS better to retrigger a test suite rather than a test case, in most cases.

[m-linner-ericsson]

Assume that we would introduce a new link type called TRIGGERED_BY. We require that each activity that has been triggered by an Eiffel event shall also provide a TRIGGERED_BY link.

Could we then use CAUSE to point to the SCC/SCS event in the re-triggered activity?
Could we then use the previous_activity_execution (in ActS) to link to the previous activity that was re-triggered?

[magnusbaeck]

What's the semantic difference between TRIGGERED_BY and CAUSE in the example above? When would you use one or the other?

The documentation isn't clear on whether a CAUSE denotes the direct cause, i.e. did the link's target event actually trigger the source event (i.e. CAUSE is basically a synonym to TRIGGERED_BY), or if a more figurative meaning of causality is acceptable.

[e-backmark-ericsson]

This is not an answer to Magnus' question above, and I might be going down a dangerous rabbit hole here, but could a "retriggered" activity rather be seen as a "restarted" activity? If yes then we shouldn't send a new ActT event, but rather just an ActS event linking to the same ActT event. But...

• What would such a link from the new ActS event to the old ActT event be? It might be confusing to use ACTIVITY_EXECUTION again, or?
• Current consumers would be confused when an already finished activity was started again, but in some sense semantically it is restarted and not retriggered. And it could have been restarted (restart_type) manually or automatically by some machine.
• We wouldn't be able to handle the queueing part of the activity execution for the restarted activity though

An ActT event today serves two purposes - Defining an activity and also stating what triggered it. Some of this would maybe have been clearer if we didn't see the ActT event as the event that defines the activity, but rather had an ActivityDefined event combined with it.

[magnusbaeck]

Comments from the 2023-01-19 protocol workshop:

• PRECURSOR isn't good enough since it only describes that "A happened before B", and that's semantically different from "A retries B".
• Similarly, PREVIOUS_ACTIVITY_EXECUTION expresses a mere temporal relationship.
• The link type would clearly add value and we couldn't find any good reasons to not allow this expressiveness.
• To comply with the design guidelines and remain consistent with other intra-activity link types, maybe go with RETRIGGERED_ACTIVITY_EXECUTION?