Repository navigation
🐛 ci(scorecard): skip push runs on non-default branches (v6) - #17415
Conversation
Scorecard only analyses the default branch, so every push to another release line failed with 'Only the default branch v5 is supported'. Guard the job on event/ref so those runs show as skipped. Fixes #17392 Signed-off-by: Andrew Anderson <andy@clubanderson.com>
kubestellar-prow
Bot
added
the
dco-signoff: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubestellar-prow
Bot
added
the
size/XS
Generated by changelog-fragment-guard from the PR title (#5675). Edit the wording freely, or replace this file with the no-changelog label if the change is not user-visible. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: clubanderson <407614+clubanderson@users.noreply.github.com>
Open PR overlap checkBase branch: Conflicts are checked with every PR merged onto the current tip of No conflicting open PRs or same-file overlaps were found. |
|
Hive status — updated in place; edits do not notify. Full history is in the Activity Monitor. clubanderson this PR is held at Why:
Next: the hive does not push to your branch. Push a new head (or reply here); CI and the review swarm re-run automatically and the PR returns to the normal path. Review findings from The workflow change is correct; the PR is red only because of a malformed changelog fragment. Guard ( Blocker —
Minor: both PRs say |
![hivecommons-hive[bot]](https://avatars.githubusercontent.com/in/3568013?s=60&v=4){kind=small}
There was a problem hiding this comment.
The workflow change looks correct to me; the red check is a changelog-fragment format problem, not the code.
Workflow — .github/workflows/scorecard.yml:17-18 adds if: github.event_name != 'push' || github.ref_name == github.event.repository.default_branch on the analysis job. Read against the v6 tree: the trigger is still push: branches: [main, v4, v5, v6] plus schedule/workflow_dispatch, so non-default pushes now skip instead of hitting Only the default branch … is supported, and schedule/dispatch are untouched. This is Option A verbatim from #17392 (labelled approved-direction), so no decision is outstanding. The permissions block is unchanged.
Why changelog-fragment-guard fails — changelog.d/fixed-scorecard-default-branch-guard.md:1 starts with ci: Scorecard push runs …, no - bullet. src/scripts/check-changelog-fragment.sh:71-76 on v6 requires every fragment's first line to begin with - (or a <!-- release: … --> marker) and exits 1 otherwise — that is the exact error in the job log (run 42666100756). The second fragment changelog.d/fixed-17415.md is already well-formed and describes the same change, so the simplest fix is to delete fixed-scorecard-default-branch-guard.md (or prefix its line with - and drop the other). Either way the PR should carry one fragment, not two.
Nothing else found. This is a comment, not an approval.
— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88
37d43fa
ℹ️ Sentinel notice — informational; author is trusted (owner), merge is not blockedHive flagged this PR (author @clubanderson, head
Hive did not add the |
|
changelog-fragment-guard is red because or, if you want to keep it, prefix the line with 🐝 Hive Agent: — hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88 |
Signed-off-by: Andrew Anderson <andy@clubanderson.com>
There was a problem hiding this comment.
Looks correct to me; this is Option A exactly as #17392 proposed, and the issue already carries approved-direction.
Verified against .github/workflows/scorecard.yml on v6: the push trigger lists main, v4, v5, v6 (line 7), and the new job-level if: (line 18) lets schedule/workflow_dispatch through while skipping pushes whose github.ref_name is not github.event.repository.default_branch (currently v5) — so v6 pushes go from red to skipped, which is the issue's complaint. No change to the permissions: block or the pinned reusable-workflow SHA. #17414 is the same guard on the v5 line, not a duplicate — the release-lines-in-sync check expects both.
One small thing: the PR ships two changelog fragments for one change — changelog.d/fixed-17415.md and changelog.d/fixed-scorecard-default-branch-guard.md — so the release notes will carry the same bullet twice. If fixed-17415.md was auto-added, the hand-written one is the better of the two to keep. Not blocking.
— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88
|
Thank you for your contribution! Your PR has been merged. We'd love to hear how your experience was: share feedback |
… the pick The one-PR-per-issue rule and the cross-lane claim-conflict gate ran over every open candidate on every sweep, regardless of CI or review state, and the winner flipped the moment either head had a red check. hivecommons#17414/hivecommons#17415 read "needs human decision · Let hive decide" with CI at 19/64 and swapped duplicate-of numbers as checks went red and green. - A same-issue PR is held (duplicate-of / claim-conflict) only once the lane last saw its head at the merge gate, the readiness a train seat needs. Short of the gate it is evaluated on its normal path, so its row reads CI / Review, and carries a turn the merge point checks: an undecided claim conflict holds it there; otherwise the first PR of the issue at the merge point takes the issue and the rest yield to it. - The pick is remembered per lane and issue and stands until the kept PR closes or is blocked for good (human merge, not mergeable, terminal required-check hold, permanent refusal); a red check does not flip it. - A merge-point hold verdict reads as merge-gate readiness, so the held PR is held at the gate from the next pass. - The delegate no longer promises a re-pick on the next pass. Hive-Run: hivecommons#17439 Hive-Plan: issue-17439 options A+C (defer to the merge gate, stable winner) Hive-Spec: hivecommons#17439#expected Co-authored-by: clubanderson <407614+clubanderson@users.noreply.github.com> Signed-off-by: Karibhou <Karibhou@users.noreply.github.com>
… the pick The one-PR-per-issue rule and the cross-lane claim-conflict gate ran over every open candidate on every sweep, regardless of CI or review state, and the winner flipped the moment either head had a red check. hivecommons#17414/hivecommons#17415 read "needs human decision · Let hive decide" with CI at 19/64 and swapped duplicate-of numbers as checks went red and green. - A same-issue PR is held (duplicate-of / claim-conflict) only once the lane last saw its head at the merge gate, the readiness a train seat needs. Short of the gate it is evaluated on its normal path, so its row reads CI / Review, and carries a turn the merge point checks: an undecided claim conflict holds it there; otherwise the first PR of the issue at the merge point takes the issue and the rest yield to it. - The pick is remembered per lane and issue and stands until the kept PR closes or is blocked for good (human merge, not mergeable, terminal required-check hold, permanent refusal); a red check does not flip it. - A merge-point hold verdict reads as merge-gate readiness, so the held PR is held at the gate from the next pass. - The delegate no longer promises a re-pick on the next pass. Hive-Run: hivecommons#17439 Hive-Plan: issue-17439 options A+C (defer to the merge gate, stable winner) Hive-Spec: hivecommons#17439#expected Co-authored-by: clubanderson <407614+clubanderson@users.noreply.github.com> Signed-off-by: Karibhou <Karibhou@users.noreply.github.com>
… the pick (#17444) * 🐛 fix(automerge): hold same-issue PRs only at the merge gate and keep the pick The one-PR-per-issue rule and the cross-lane claim-conflict gate ran over every open candidate on every sweep, regardless of CI or review state, and the winner flipped the moment either head had a red check. #17414/#17415 read "needs human decision · Let hive decide" with CI at 19/64 and swapped duplicate-of numbers as checks went red and green. - A same-issue PR is held (duplicate-of / claim-conflict) only once the lane last saw its head at the merge gate, the readiness a train seat needs. Short of the gate it is evaluated on its normal path, so its row reads CI / Review, and carries a turn the merge point checks: an undecided claim conflict holds it there; otherwise the first PR of the issue at the merge point takes the issue and the rest yield to it. - The pick is remembered per lane and issue and stands until the kept PR closes or is blocked for good (human merge, not mergeable, terminal required-check hold, permanent refusal); a red check does not flip it. - A merge-point hold verdict reads as merge-gate readiness, so the held PR is held at the gate from the next pass. - The delegate no longer promises a re-pick on the next pass. Hive-Run: #17439 Hive-Plan: issue-17439 options A+C (defer to the merge gate, stable winner) Hive-Spec: #17439#expected Co-authored-by: clubanderson <407614+clubanderson@users.noreply.github.com> Signed-off-by: Karibhou <Karibhou@users.noreply.github.com> * 🐛 fix(automerge): key the same-issue winner by base; keep it when the claimant read fell back Review follow-up on #17444: a forge-state read failure on an event-narrowed pass no longer forgets a still-open remembered winner, and v5/v6 siblings no longer share one mergeTrainIssueWinners entry. Signed-off-by: Karibhou <Karibhou@users.noreply.github.com> --------- Signed-off-by: Karibhou <Karibhou@users.noreply.github.com> Co-authored-by: Karibhou <Karibhou@users.noreply.github.com> Co-authored-by: clubanderson <407614+clubanderson@users.noreply.github.com> Co-authored-by: hivecommons-hive[bot] <280983584+hivecommons-hive[bot]@users.noreply.github.com>
Option A from #17392: guard the Scorecard job so pushes to non-default release lines are skipped instead of red. Same change on both lines.
Fixes #17392