-
🔰 fundamental topics for beginners getting started with DevSensei
-
🔬 advanced topics for once you have your first workflows automated
The retrigger-on section is optional. If configured, it defines a set of expressions that are continuously evaluated, similar to conditions.
Example
retrigger-on:
- destination
- diff-change
It provides more fine-grained control over when edge-triggering occurs. Normally, actions only run on the "edge" when the condition changes from "not-met" to "met". For example, if attribute values change, but the condition is still met, then normally actions will not run again.
However, if retrigger-on is configured, then whenever one of its expression values changes while the condition is met, the signal for the condition will temporarily flip, enabling a new edge-trigger even though the condition is already met.
Concept of retrigger-on
The below code block illustrates three timelines: (A) the periods of time where the condition remains true; (B) the instants where the condition flips to true; (C) the instants where retrigger-on measures a change in a retrigger-expression’s value.
condition (A): ▁▁┌──────────────┐▁▁▁▁▁┌───┐▁▁
conditionEdge (B): ▁▁╷▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁╷▁▁▁▁▁▁
retrigger-on (C): ▁▁╷▁▁▁╷▁▁▁▁╷▁▁▁▁▁▁▁▁▁▁▁╷▁▁▁▁▁▁
Without the retrigger-on section the workflow actions would only run twice. The effect of retrigger-on makes it so that the workflow actions actually run 4 times instead.
Retrigger Expressions
Concretely, in a single expression you can either specify a watchable attribute, or observe changes to the combined diff.
|
Kind |
Syntax |
What is compared on each change |
|---|---|---|
|
|
|
the value of the attribute - note that only watchable (⚡️) attributes are supported. |
|
|
|
the computed overall change in the diff, ignoring other commit metadata. |
Look at the attributes table to see which are watchable (labelled with ⚡️). Let us know if you would like more kinds of checks to be supported in this section.