We’ve interested in two sorts of block steps:
- “critical” block steps, where a build cannot continue without it, and isn’t validated without user input. Examples:
- we have an open source pipeline where we want an approved committer to unblock the build, representing an approval/validation before running the arbitrary external code on our CI (for instance, stellargraph-public #171)
- we’re using gitflow, and have set up enough automation so that QA for a release happens via a PR from
release/x.y.z
tomaster
, and CI tests that vigorously, along with a release checklist for a few final pieces that are impossible/costly to automate. The release PR shouldn’t merge without checking that release checklist, and we use a block step to remind/force us to do this.
- “optional” block steps, where there’s extra actions one might occasionally want to trigger. Examples:
- a release can start from any commit on
develop
, and it’s nice to have the start of that process as an automated step that can optionally be triggered by just clicking a button on the BK UI
- a release can start from any commit on
These are quite different, and the GitHub status for each should be different:
- “critical” blocks need to be
pending
: the testing hasn’t finished and isn’t successful, when the build blocks, and so this shouldn’t fulfil any GitHub required status checks - “optional” blocks need to be
passed
: the testing is successful, and any status checks should be fulfilled
This can be somewhat controlled using “Pipeline settings > GitHub > GitHub Settings” configuration, but it forces each pipeline to choose only one of the above because it seems to be global.
Is there a way to control this in a more fine-grained way (e.g. mark an individual block step as pending_when_blocked: true
or status: pending
/status: passed
something)?