A resource solely for triggering concourse builds when resources are added to pools.
When a single job is configured to trigger on this resource it guarantees one triggered build for every unclaimed lock that is in the pool when the resource is created and one for each lock added afterwards.
Do not use it to get or put locks.
Behaviour is only guaranteed if
1. A SINGLE job triggers on the configured pool.
2. No other job claims locks on the same pool.
pool-trigger resource in addition to a normal
resource for the same pool with identical parameters. Then add a
step to your job referencing the
pool-trigger and a
acquire: true. Don't expect anything useful
pool-trigger as an input - the
in script is a no-op.
An example showing an infinite loop that moves locks back and forth
between two pools forever can be found here:
- Checks for newly added locks since the last version (or any currently
unclaimed if starting fresh with no previous version) and adds these
to the tally in
- Checks for removed locks and subtracts them from the tally in
- Any locks removed in excess of
.pending-removalsare removed from
- If the
.pending-triggerstally is greater than zero it decrements the
.pending-removalsand returns the previous commit hash reference
- If the
.pending-triggerstally is zero it returns no new references
checkfails to push the updated
.pending-triggerstally it will fail out. This should only happen if other commits are pushed in between fetching and pushing the tally. It should resolve itself on the next check with no intervention.
- If a build fails before the claim step happens (usually due to a concourse/aws connection error) it will be necessary to manually re-trigger the build.
- If for any reason things get all wonky things can be re-initialized by deleting