An example would have the following jobs run for every commit on master:
- deploy to staging
- selenium tests on staging
tests, and build can run in parallel from other commits. For example User A merges PR 1 roughly the same time as User B merges PR 2. Both merges kick off a new workflow. tests and build can run in parallel (meaning tests for PR 1 can run at the same time as PR 2).
However, we want to make sure that "deploy to staging" followed by "selenium tests" can only be run in order and are dependent. Meaning deploy for PR 2 cannot start until selenium completes.
So what we end up with in our build history is something like
- tests (PR1) (Success)
- build (PR1) (Success)
- deploy to staging (PR1) (Running)
- selenium tests on staging (PR1) (Queued/Not Running yet because of requires deploy to complete)
- tests (PR2) (Success)
- build (PR2) (Success)
- deploy to staging (PR2) (Queued/Not Running yet because of PR 1 deploy)
- selenium tests on staging (PR2) (Queued/Not Running yet because of requires deploy to complete)
At the time of writing this, I'm doing an API call for builds to try and sort and filter them to see if anything running can block my flow. However, because a circle build run that requires another circle build run (ie selenium requires deploy to complete first), the selenium build has not been "created" yet. And when it does, it will have a build id greater than any build id for PR2.
Since I cannot query the workflow API, I have to try and depend on inconsistent attributes of a build (ie date from the commit being older when the build id is newer). This is prone to bugs or causing infinite loop (one build requires the other and visa versa).
Are there any other solutions that may alleviate this?