How to always keep your stack in sync without triggering a new run
Last updated: July 14, 2025
Understanding the conditions
The track decision sets the new head commit on the affected stack or module. This head commit is what is going to be used when a tracked run is manually triggered, or a task is started on the stack. Usually what you want in this case is to have a new tracked Run, so this is what we do by default.
So if what you want is an option to set the head commit, but not trigger a run. This is what the boolean notrigger rule can do for you. notrigger will only work in conjunction with track decision and will prevent the tracked run from being created.
Please note that notrigger does not depend in any way on the track rule - they're entirely independent. Only when interpreting the result of the policy, we will only look at notrigger if track evaluates to true
Example Policy Snippet
Below is a sample snippet that sets the head commit on the stack, but skips creating a new run under certain conditions:
# Always update the head commit
track {
true
}
# Skip triggering a run if:
# - The push does not affect the stack
# - The push is to a branch different from the stack's tracked branch
notrigger {
not affected
not input.push.branch == input.stack.branch
}This logic ensures your stack stays in sync, but avoids unnecessary runs—particularly useful for housekeeping commits or updates to long-lived feature branches.
Implementation Tips
To get the most out of this pattern:
Invert your usual
tracklogic when writingnotrigger. If your typicaltrackrule runs only under specific conditions, yournotriggershould mirror the inverse of those conditions.Use a complete policy. The above snippet must be part of a full push policy that accounts for all your relevant conditions and organizational rules.
Test your policy. Before deploying it broadly, validate the behavior using your policy workbench.
Learn More
For a deeper understanding of track, notrigger, and related corner cases, check out our Push Policy documentation.