ci(connectors): run connector tests post-merge instead of in the merge queue

Merged
JM
5mo ago
+21-1

What

Stop running the Connector Tests workflow on merge_group. Run it on push to main (post-merge) instead, alongside the existing PR presubmit and daily schedule.

Why

Connector tests have been intermittently failing in the merge queue with:

git fetch --no-tags --depth=100 origin main gh-readonly-queue/main/pr-11356-...
fatal: couldn't find remote ref gh-readonly-queue/main/pr-11356-...
##[error]The process '/usr/bin/git' failed with exit code 128

(example run)

The merge queue tests each entry on an ephemeral gh-readonly-queue/* branch. dorny/paths-filter computes its diff by fetching the head ref by name to find the merge-base. When an entry ahead in the queue fails (or the queue is reordered/dequeued), GitHub deletes and recreates the queue branches with new SHAs. If that happens mid-run, the by-name fetch hits a ref that no longer exists → exit 128 → the whole job goes red, unrelated to the change under test.

Why only the connector workflow hits this: its paths-filter step runs inside connectors-check, which needs: build-backend-image — so it executes ~3+ minutes after the event, a wide window for the queue branch to be torn down. The other workflows run paths-filter in a no-needs: changes job within seconds of the event, so they almost never race it.

Why moving it off the queue is safe: connectors-check is not a required status check (main's ruleset requires only quality-checks, playwright-required, database-tests, backend-check, mypy-check, Jest Tests, required). It's non-blocking and exercises real external connector APIs — exactly the kind of slow/flaky suite that doesn't belong in the merge queue. Running it on merge_group gated nothing and only added a race surface.

How

  • Remove the merge_group: trigger.
  • Add push: branches: [main] so the suite runs post-merge against main (a permanent ref — the branch-deletion race cannot occur).
  • Scope the push trigger with the same paths: as the PR trigger so unrelated (e.g. frontend-only) merges don't run it. paths is not evaluated for tag pushes, so the existing v*.*.* release trigger still fires regardless of changed files.
  • PR presubmit (pre-merge signal) and the daily schedule (full-coverage safety net, with its Slack alert) are unchanged.

Post-merge is detection rather than prevention, but since these tests were already non-blocking, no gating is lost — and the daily cron's Slack alert remains the signal for "broken vs. flaky."

Test plan

  • Workflow YAML parses; triggers are now pull_request, push, schedule with push = {branches:[main], paths, tags}
  • Confirm a merge to main triggers the run and a frontend-only merge does not

🤖 Generated with Claude Code

Summary by cubic

Run connector tests on pushes to main (post-merge) instead of in the merge queue to eliminate flaky failures from ephemeral gh-readonly-queue/* branches. PR presubmit and the daily schedule remain; tag releases still trigger.

  • Refactors
    • Removed merge_group trigger.
    • Added push: branches: [main] with paths filter to avoid unrelated runs.
    • Avoids dorny/paths-filter by-name fetch failures when queue branches are recycled.