[quality] test.yml never runs on main after a tide merge — github.token merges don't trigger push; add workflow_dispatch + schedule #329

Finding

main has had no build-test run since a270568 (2026-10-03T05:05Z) even though three commits landed after it. .github/workflows/test.yml runs on: [push, pull_request], but merges performed by tide (src/plugins/tide.ts, running under prow-bot.yml with the default github.token) are made by github-actions[bot], and GitHub does not create workflow runs for events caused by GITHUB_TOKEN. So the post-merge push run only fires when a human presses the merge button:

(gh api repos/cncf/prow-github-actions/actions/workflows/1003542/runs?event=push&branch=main lists a270568 as the newest; gh api repos/cncf/prow-github-actions/pulls/278 --jq .merged_by.login → github-actions[bot].)

Consequence: the default branch's "green" is whatever the last human-merged commit scored, which is exactly the baseline #294 leans on ("main's last runs are green"). In fact main @ 3fc21f2 is red: npm run test:coverage locally (Node v26.10.0, vitest 5.0.3) → 80 files / 1639 tests pass, 1 unhandled error (ERR_TLS_CERT_ALTNAME_INVALID from __tests__/issueCommentTest/meow.test.ts) — the msw 3 regression #278 brought in, which its own pull_request runs (37146633824, 37146629137) happened to pass. Nothing has ever run build-test on the merged result, and there is no way to ask for one: test.yml has no workflow_dispatch.

Recommendation

Give main a build-test baseline that does not depend on who merged, and a way to re-run it on demand. One mechanical edit to .github/workflows/test.yml — replace line 2:

on: [push, pull_request]

with

on:
  push:
  pull_request:
  workflow_dispatch:
  schedule:
    - cron: '17 6 * * *'

workflow_dispatch lets a maintainer re-run the baseline (gh workflow run test.yml --ref main) when triaging an incident like #294; the daily schedule catches regressions that tide merges in. The job body is unchanged, so required-check semantics on pull requests are untouched.

Alternative, if the maintainers prefer merges themselves to trigger CI: have prow-bot.yml pass a non-GITHUB_TOKEN credential through prow.yml's existing secrets.token input, so tide's merges are attributed to an App/PAT and fire push. That needs a secret and a decision about which identity merges, so it is not proposed as the default here.

• .github/workflows/test.yml: add workflow_dispatch and schedule triggers (replacement text above)

Why this is an issue and not a PR

The change is entirely inside .github/workflows/. This agent's App token is minted at the contributor tier without the Workflows permission, so GitHub rejects any push touching that directory server-side. Applying the replacement above needs a human or an ISSUES_PRS_MERGE agent; it is a four-line mechanical edit.

Related: #294 (the stale-baseline incident this exposes), #213 (push + pull_request double-running same-repo PRs — the on: block above keeps both and is compatible with whichever fix #213 picks).

Priority

• Impact: high — the default branch has no CI signal after bot merges; a red main is currently invisible
• Effort: low

Filed by quality agent (hold-gated mode)

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

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