Read the triggers and the conditions into the parity document (#62) - #144
Merged
iderex merged 1 commit intoAug 17, 2026
Merged
Conversation
Two of the ways a required context never arrives are readable in the workflow files rather than walked: a trigger that runs on some pull requests only, and a job skipped by a condition. Neither reading was in this document, which is where the issue asks for the result, and the one that existed at all was made before one of these workflow files was written. The failure it prevents is a required set assembled from names nothing has been checked for arrival on, with the document beside the set silent about which names were read for it and at which commit. The section names that commit, carries the command behind every line, and says what the commands do not reach: a fourth route written some other way, and what a job does once it has started. Nothing here closes the issue. Its first clause needs a required set to compare against and the set is empty, and no pull request from a fork has been opened on this board. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #62
What this changes
The document gains a section under the walk of which contexts arrive, saying
which of the ways a required context can fail to arrive are readable in the
workflow files and what those files say today. Three commands and their output:
no workflow carries a path filter, three files carry no branch filter that
reads every branch and none of the three narrows a pull request by it, and two
files carry a condition at all, neither of them on a name the table keeps.
Nothing else in the document moves and no other file is touched.
What failure it prevents
A required set assembled from names that arrive on some pull requests only,
with the document beside the set silent about which names were read for it. The
reading that existed at all lived outside the tree and was made before one of
these workflow files was written, so a reader asking what stands behind a merge
could not find it where the rest of the walk is, and could not tell how much of
the tree it had covered.
What was run
I ran the four commands CONTRIBUTING.md names, at the commit being pushed, and
the checker over this tree. The suite output is the tail of the run.
The invariants leg refused this change twice before it was written the way it
is now. The first draft pasted
git grep -A1output, whose context lines end apath with a dash, and
document-names-a-path-that-does-not-resolverefusedboth of them by name:
Every command the section quotes was run at
1fc6961and its output pastedfrom that run rather than retyped.
What this does not do
This is not the end of #62. The first clause of that issue compares what arrives
against the required set, the set on this board is empty, so there is nothing
to compare against. The fork clause is untouched: no pull request from a fork
has been opened on this board and nothing here opens one.
It says nothing about what a job does once it has started. A context that
arrives having done nothing is a different question, and the section says so
where it states its bound.
One line in it is a claim rather than a measurement, and it is written as a
claim: that the three event types
dco.ymlnames are the three the platformruns a pull-request workflow for when a file names none. That is the platform's
documented default, and nothing in this tree measures it.
There is no second reader for this change tonight. What stands in place of one
is the output above and the commands in the section, each of which reproduces
against
origin/main.