fix(ci): a used-by submission reaches its pull request regardless of how it was filed - #530
Merged
Merged
Conversation
…hout blank lines Three faults made approved submissions end without a pull request, and none of them left a red run. The job keyed on the "approved" label arriving last. A submission that reaches the tracker outside the web form carries no template label, so the maintainer adds "used-by-submission" after "approved" is already on; that event failed `github.event.label.name == 'approved'` and no run started. The only way out was to remove and re-apply "approved" by hand, which is what happened on #525 and #484. The condition now accepts either label as the one that arrives last. The parser splits a section into key and value on the blank line the web form writes after each "### " heading. A body without it collapses the section into the key, leaves the value undefined, and JSON.stringify drops undefined, so the whole form returns {}. #525 arrived that way: two runs went green, read every field as missing, and opened nothing. The body is now normalised before parsing, which fixes that shape and leaves the web-form shape untouched. An unreadable submission exited 0, so a failed parse was indistinguishable from success: green run, no PR, no notification. It now fails loudly and names the missing fields. Two further silent no-ops are closed with it, a missing pair of README markers and an insert that changed nothing, plus a check that the PR step actually produced a PR. Verified by replaying the real #525 and #497 bodies through the workflow's own steps: #525 now parses and inserts, #497 is unchanged, free text fails with exit 1, and a duplicate still skips at exit 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VDKAJrLjLXVsCvJVNdJEPw
…orm's label The "used-by-submission" label from the issue form only lands when the issue is really filed through the web form, and most submissions are not. Measured across the 256 issues opened by other people, 114 carry a template label at all, so 55% reach the tracker past the templates, through the API, gh, a mobile client or a body pasted from somewhere else. Two of the nine used-by submissions came in that way and had to be labelled by hand before anything could run. Recognise the submission by its shape instead: a "[Used by]" title, or a body carrying the form's own headings. Checked against every issue in the tracker, the condition matches all nine used-by submissions and nothing else. This only ever adds "used-by-submission". "approved" stays a maintainer action and remains the thing that opens a pull request. A label set with GITHUB_TOKEN starts no further workflow run, which is the order we want anyway: the label lands at submission time, the later human "approved" is the event that starts the run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VDKAJrLjLXVsCvJVNdJEPw
superuser404notfound
changed the title
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
1 participant
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.
Approved submissions were ending without a pull request, and no run ever went red.
Why the label was missing
The
used-by-submissionlabel from the issue form only lands when the issue is really filed through the web form. Measured across the 256 issues opened by other people in this tracker:gh, a mobile client, or a body pasted from somewhere else.blank_issues_enabled: falsedoes not stop any of those.###headings, issues without one mostly have no headings at all.Two of the nine used-by submissions (#484, #525) arrived that way and had to be labelled by hand.
What was wrong
1. The label order decided whether anything ran. The job required
approvedto be the label that arrived. When the maintainer adds the missingused-by-submissionafterwards, that event does not match, so nothing runs. The only escape was removing and re-applyingapprovedby hand.Timeline of #525, the whole trap in three events:
approvedadded (issue had noused-by-submission)used-by-submissionaddedapprovedremoved and re-applied by hand2. The parser returns
{}when the body has no blank line after a heading.github-issue-parsersplits a section into key and value on/\r?\n\r?\n/. Without the blank line the whole section becomes the key, the value isundefined, andJSON.stringifydrops undefined keys. #525 arrived in exactly that shape; its log showsISSUE_JSON: {}then "Missing a required field".3. A failed parse was indistinguishable from a success. It exited 0, so the run went green with no PR and no notification. #525 has two green runs and no PR.
What changed
used-by-add.ymlapprovedstarts the run.###heading, code fences respected) before it reaches the parser. Fixes the broken shape, leaves the web-form shape untouched.add-paths: README.mdso no runner file can ride along in the commit.used-by-label.yml(new)[Used by]title, or the form's headings in the body) and appliesused-by-submissionitself, so the label no longer depends on how the issue was filed.approvedstays a maintainer action and remains the thing that opens a pull request.Verification
The workflow's own
run:steps replayed against the real issue bodies:{}, green, no PR- [Vivid](https://github.com/blurbery/vivid): open-source media app for iPhone, iPad and Apple TV.The labelling condition evaluated against every issue in the tracker: 9 of 9 used-by submissions matched, 0 false positives across 256 issues, 0 missed.
Workflow events run from the default branch, so this only takes effect once merged. After merging, re-applying either label on #525 opens the Vivid PR.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VDKAJrLjLXVsCvJVNdJEPw