We have a pipeline for our master branches. If multiple merges are made to that branch, we want to effectively queue up the pipelines such that only 1 master pipeline on that repo is being run.
If the currently running pipeline completes successfully, then the next pipeline in waiting can go ahead.
If the currently running pipeline fails, then this effectively stalls the queue and someone will be along shortly to sort it out.
Our current solution is quite daft and is only half providing the requirement. We have a separate repo with 1 commit and we then add tags for each of the main repos when it is deploying. The master branch of the main repos see if the tag exists. If it does, it aborts the pipeline. No waiting/queueing.
In the event of a failure, we have tooling to remove the tag and we decide what to do next. Either re-run the failed steps in the original pipeline, or run the next pipeline. Each event requires a human (at the moment) to judge the failure and decide a course of action.
But having this 'state' being maintained via tags on an almost empty external repo, whist "it works", is not a nice solution.
Is there any sort of repo state that can be written to and read from within the pipeline? Something that would not normally be interacted with by doing anything within BitBucket, or externally via git, related to the repo's content (tags, branches) as those things can easily be changed by someone pushing tags from a repo, etc.
One option would be to have a repo specific variable that is read/written to within the pipeline. Is that's something doable?
How many steps does this pipeline for master branch have?
If it has only one step, you could use the deployment keyword for this step and a deployment environment.
If a deployment step is in progress and another deployment step gets triggered, then the latter one will get paused automatically.
Paused deployments cannot be resumed automatically, they need to be manually resumed.
However, you could use an after-script in your pipeline's step. In the after-script, you can check the $BITBUCKET_EXIT_CODE of the step, and if it is a success, then:
- check if the last build on that branch is paused
- if it is paused, you can trigger a new deployment via our API
We have a feature request for automatically resuming paused deployments. In one of the comments, another customer posted a bash script they used in order to check for paused deployments and start a new one:
You can check the script and adjust it to your needs.
Please feel free to let me know if your pipeline has multiple steps and it's not possible to combine these steps into one, and I can look into a way to achieve something similar with a multi-step pipeline.