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?
