QVAC-18613 infra: recognise verified label as explicit tier 1 in approval bot#2006
Closed
Proletter wants to merge 2 commits into
Closed
QVAC-18613 infra: recognise verified label as explicit tier 1 in approval bot#2006Proletter wants to merge 2 commits into
Proletter wants to merge 2 commits into
Conversation
…oval bot The tier-based approval check previously defaulted to tier 1 if no \`tier2\` label was present, treating tier 1 as an implicit fallback. Per QVAC-18190 the \`verified\` label landing in #1997 should also be the explicit tier-1 marker, so reviewers can see in the bot comment *why* a PR is at tier 1 (because it's verified, vs. because no tier label is set). Behaviour matrix (matches QVAC-18613 acceptance criteria): | Labels on PR | Tier | Bot comment "Tier source" | |------------------|-------|----------------------------------------------------| | neither | tier1 | default (no tier label applied) | | \`verified\` only | tier1 | \`verified\` label applied (explicit tier 1) | | \`tier2\` only | tier2 | \`tier2\` label applied | | both | tier2 | \`tier2\` label applied (overrides \`verified\`) | Precedence rationale: \`tier2\` wins when both labels are present. Stricter requirements take priority on conflict. The matrix above is preserved verbatim in the bot comment so the reviewer can verify the active rule without reading code. Backwards compatibility: PRs with neither label keep the prior behaviour exactly (tier 1 default, same requirements computation). PRs with only \`tier2\` keep the prior behaviour exactly. The only new code paths are the \`verified\`-only and both-labels cases. Implementation: - New \`hasVerified\` / \`hasTier2\` locals. - New \`tierSource\` string threaded through \`checkTierRequirements\` and \`comment\` so the bot output mentions \`verified\` per AC #2. - Bot comment gains a \`**Tier source:**\` line right under \`**PR Tier:**\` so the source is visible without expanding logs. Validation plan: - Marked draft pending #1997 (label-gate fan-out) merge so the \`verified\` label is actually applied in the wild. - Test matrix walkthrough on a throwaway PR with each of the 4 label combinations + \`/review\` comment to trigger the worker. - Confirm the bot comment shows the expected "Tier source" string in each case and the requirementsMet decision is unchanged from the previous logic. Co-authored-by: Cursor <cursoragent@cursor.com>
Preview deployments for qvac-docs-staging ⚡️
Commit: Deployment ID: Static site name: |
Contributor
Tier-based Approval Status |
4 tasks
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.
🎯 What problem does this PR solve?
The tier-based approval bot defaulted to tier 1 if no
tier2label was present. With theverifiedlabel landing in QVAC-18612 infra: gate every secret-bearing workflow with label-gate #1997 as the explicit tier-1 security marker (per QVAC-18190), reviewers had no way to see why a PR was at tier 1 — implicit-default vs. explicitly-verified looked identical in the bot comment.Per QVAC-18613 AC: the bot needs to recognise
verifiedas the explicit tier-1 marker AND mentionverifiedin the tier explanation, so reviewers can audit the gate decision without reading worker source.📝 How does it solve it?
Single surgical change to
.github/workflows/approval-check-worker.yml:tier1default (no tier label applied)verifiedonlytier1`verified` label applied (explicit tier 1)tier2onlytier2`tier2` label appliedtier2(stricter wins)`tier2` label applied (overrides `verified`)hasVerified/hasTier2locals + atierSourcestring threaded throughcheckTierRequirementsandcommentso the bot output mentionsverifiedper AC add public reusable for qvac-cli #2.**Tier source:**line right under**PR Tier:**so the source is visible without expanding logs.tier2wins when both labels are present — stricter requirements take priority on conflict. Documented inline in the worker.Backwards compatibility: PRs with neither label keep the prior behaviour exactly. PRs with only
tier2keep the prior behaviour exactly. The only new code paths areverified-only and both-labels.🧪 How was it tested?
actionlintclean on the modified workflow.node --checkon the embeddedactions/github-scriptbody — clean.tierSourcepresent at every call site.Pending live validation (to be performed before flipping out of Draft, after #1997 lands):
/reviewwith no labels → bot says "Tier source: default (no tier label applied)" + tier 1 requirements.verified→ bot updates to "Tier source:verifiedlabel applied (explicit tier 1)" + tier 1 requirements.tier2(still hasverified) → bot updates to "Tier source:tier2label applied (overridesverified)" + tier 2 requirements.verified→ bot updates to "Tier source:tier2label applied" + tier 2 requirements (unchanged from previous behaviour).tier2→ back to "default" + tier 1.🔗 Related
docs/ci/LABELS.mdalready statesverified"is recognised as tier 1 byapproval-check-worker").Made with Cursor