This is the issue the rest of the milestone exists for, and it is the one that
changes the repository settings rather than the tree.
The ruleset on the default branch of this board today refuses deletion and
force-pushes and requires a pull request, and requires no status check whatsoever.
Every workflow in the tree runs and none of them holds a merge. A red tick and a
green tick have the same effect on whether a change lands, which means the checks
are currently documentation.
Print the current state rather than trusting this paragraph:
gh api repos/Flowfin/lab/rules/branches/main \
--jq '.[] | select(.type=="required_status_checks")
| .parameters.required_status_checks[].context'
Add every check name the parity document keeps to the required set, using the exact
context strings the runs report, taken from a completed run rather than from a
workflow file, because a job name and a check-run name are not always the same
string and the difference is invisible until a required check never arrives.
Keep the ruleset with no bypass actors, so it holds for everybody including whoever
administers the repository. A gate with an exception for the person most likely to
be in a hurry is not a gate.
One consequence to accept deliberately. Once this lands, a failed workflow blocks a
merge on a board whose entire purpose is to allow failure. That is correct, because
none of these checks judges whether an experiment worked. They judge the record,
the tree and the change. An experiment that answered no passes all of them.
Done when the command above lists every check the parity document keeps, the
ruleset still has no bypass actors, and a pull request with a deliberately failing
check is shown to be unmergeable.
This is the issue the rest of the milestone exists for, and it is the one that
changes the repository settings rather than the tree.
The ruleset on the default branch of this board today refuses deletion and
force-pushes and requires a pull request, and requires no status check whatsoever.
Every workflow in the tree runs and none of them holds a merge. A red tick and a
green tick have the same effect on whether a change lands, which means the checks
are currently documentation.
Print the current state rather than trusting this paragraph:
Add every check name the parity document keeps to the required set, using the exact
context strings the runs report, taken from a completed run rather than from a
workflow file, because a job name and a check-run name are not always the same
string and the difference is invisible until a required check never arrives.
Keep the ruleset with no bypass actors, so it holds for everybody including whoever
administers the repository. A gate with an exception for the person most likely to
be in a hurry is not a gate.
One consequence to accept deliberately. Once this lands, a failed workflow blocks a
merge on a board whose entire purpose is to allow failure. That is correct, because
none of these checks judges whether an experiment worked. They judge the record,
the tree and the change. An experiment that answered no passes all of them.
Done when the command above lists every check the parity document keeps, the
ruleset still has no bypass actors, and a pull request with a deliberately failing
check is shown to be unmergeable.