[mrbobbytables]

Description

Consolidated fix for the two open test.yml trigger findings:

• on: [push, pull_request] ran build-test twice per commit on every same-repo PR branch, and a newer push never cancelled the pending run ([quality] test.yml runs build-test twice per commit on every PR branch — narrow push to main and add a concurrency group #213). push is now narrowed to main, and the concurrency group is keyed on the pull request number, so a newer push to a PR supersedes its pending run while same-named branches across forks never collide. Every non-PR run (main push, schedule, dispatch) falls back to its own run_id and is never cancelled or replaced.
• Merges performed by tide with github.token never fire push runs, so main had no build-test baseline after bot merges ([quality] test.yml never runs on main after a tide merge — github.token merges don't trigger push; add workflow_dispatch + schedule #329). workflow_dispatch lets a maintainer re-run the baseline on demand (gh workflow run test.yml --ref main), and a daily schedule (17 6 * * *) catches regressions tide merges in. GitHub emails scheduled-run failures to whoever last edited the cron line.

The jobs: map is unchanged, so required-check semantics on pull requests are untouched. Tag pushes no longer run test.yml; release.yml owns v* tags and runs after main was already green on the same commit.

Fixes #213
Fixes #329

Testing

Workflow-only change; the job body is untouched.

• node -e "require('js-yaml').load(...)" on the edited test.yml — parses cleanly

Checklist

• I ran npm run all to lint and build my code — not applicable, no code touched
• I ran npm run pack and committed dist/ — not applicable, dist/ unchanged
• Commits are signed off (DCO)
• Note any new dependencies these changes bring in — none
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation — none needed
• My changes generates no new warnings (please describe new warnings if unavoidable)

[github-actions]

Please add a kind label with /kind failing-test or /kind cleanup.

[hivecommons-hive]

Reviewed from the test lane (read-only on a fork head, so comment only). The trigger narrowing and the concurrency block look right:

• group: test-${{ github.head_ref || github.ref_name }} with cancel-in-progress: ${{ github.event_name == 'pull_request' }} cancels only superseded PR runs; push to main, the schedule and workflow_dispatch all land in test-main and queue rather than cancel, so no merge loses its result.
• No path filter is added, so build-test still runs (and can still be required) on every pull request.
• A repack push triggered by ci: repack dist/ on dependabot branches without exposing a write token #390 lands in the same group as the PR's own run and supersedes it, which is the desired order.

One nit on the body: prow-bot.yml keys its group on event_name/action/comment or PR id with cancel-in-progress: false (.github/workflows/prow-bot.yml:34-36), so it is not quite "the same pattern" — the head_ref || ref_name form here is the standard GitHub-documented one and is the right choice for a build-test lane, it just isn't a precedent from this repo.

git merge-tree --write-tree pr-389 pr-390 exits 0 — this and #390 merge cleanly in either order.

---

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: unknown

— hive: agent=quality backend=copilot model=claude-fable-5.1

[jeefy]

Limiting push to [main] plus pull_request does stop the double runs, and fork PRs still get CI. The concurrency key is the problem:

1. test-${{ github.head_ref || github.ref_name }} uses the branch name, which isn't unique across forks.

   • Two fork PRs from patch-1 (the web editor's default branch name) cancel each other.
   • A fork PR from its own main lands in test-main and, as a pull_request event, cancels a running main baseline.
   • Even with cancel-in-progress: false, a group keeps only one pending run, so a newer main or schedule run replaces a pending one.

   Use group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }} with cancel-in-progress: true. Then every non-PR run gets its own group and is never cancelled or replaced.

2. Fix the comment and the PR body: runs on main can be cancelled under the current key, and prow-bot.yml keys on the PR number, not the branch name.

3. Optional: say who watches the daily scheduled run. GitHub emails failures to whoever last edited the cron line.

[mrbobbytables]

Addressed all three points:

1. Concurrency group is now ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }} with cancel-in-progress: true — fork PRs from same-named branches get distinct groups, and every non-PR run (main push, schedule, dispatch) keys on its own run_id, so it is never cancelled or replaced.
2. Fixed the workflow comment and the PR body — removed the incorrect claims about main-run cancellation and the prow-bot.yml pattern.
3. Added a comment on the schedule trigger noting GitHub emails scheduled-run failures to whoever last edited the cron line.

All three review points were addressed in the follow-up commit (PR-number concurrency key, corrected comments/body, scheduled-failure note); dismissing to unblock the merge.