ci: workspace semver check runs on every push to tokio-1.*.x because the skip condition only matches pull_request events

[glaziermag]

The Check semver for rest of the workspace step in ci.yml is guarded by

if: ${{ !startsWith(github.event.pull_request.base.ref, 'tokio-1.') }}

github.event.pull_request only exists on pull_request events. On push events the operand is empty, the expression is always true, and the workspace-wide check runs, including on pushes to tokio-1.*.x release branches, which the guard was meant to exempt. The guard came from commit 7b6ccb51 ("chore: backport CI fixes", part of #7232, forward-ported in #7239/#7241), which states the intent: "Only check tokio crate as the PR is backporting to an earlier tokio release."

On tokio-1.43.x the workspace check fails for reasons unrelated to the pushed change (mechanism in the reproduction below), so every retained push run there (six, back to 2025-08-01) is red with semver as the only failing job, including the pushes at all three of the branch's release tags, cut while 1.43.x was a supported LTS:

• tokio-1.43.2 (db8edc6): https://github.com/tokio-rs/tokio/actions/runs/16673304480 (2025-08-01)
• tokio-1.43.3 (de6ef21): https://github.com/tokio-rs/tokio/actions/runs/18502115413 (2025-10-14)
• tokio-1.43.4 (dfb0f00): https://github.com/tokio-rs/tokio/actions/runs/20663875306 (2026-01-02)

The 1.43.4 sha hit both paths: the same sha passed semver in #7821's pull_request run minutes earlier (run 20663478999: the guard sees base.ref = tokio-1.43.x and skips the workspace step), then failed it in the post-merge push run. The documented release gate (CONTRIBUTING §Releasing) is the release PR's CI, which the guard keeps green; the post-merge push failure is outside that checklist.

Reproduction. On current release branches the step visibly runs rather than skipping: in the tokio-1.52.x push run 29502013411 it has conclusion success where a working guard would show skipped (it happens to pass there today). The 1.43.x failure logs have expired, so I re-ran the semver job's two steps on the tokio-1.43.4 tree in my fork, unchanged except that the if: is removed so the workspace step executes; a separate job in the same run shows how the guard evaluates on a push event. The tokio-only step passes. The workspace step fails with auto_trait_impl_removed on tokio-util v0.7.13 -> v0.7.13: the branch tree builds against in-workspace tokio 1.43.x while the crates.io baseline builds against newer tokio — the noise the guard was added to suppress:

• https://github.com/glaziermag/tokio/actions/runs/32885637709

(This is distinct from #7832/#7848, which fixed the release-time path-dep ambiguity in the minrust step; #7848 doesn't touch the semver guard.)

The active LTS branches 1.47.x and 1.51.x carry the same guard, so on the branches that ship security backports a real failure in a push run is indistinguishable from this false positive.

Two options:

1. Make the guard event-independent, e.g. !startsWith(github.event.pull_request.base.ref, 'tokio-1.') && !startsWith(github.ref_name, 'tokio-1.'), and backport it to the active tokio-1.*.x tips, since push runs use the pushed branch's own ci.yml (the guard itself reached them via backports). pull_request behavior is unchanged (ref_name is <n>/merge there); master pushes still run the check; and no signal is lost: per the quoted intent, only the tokio crate needs checking on these branches. This is what I'd do.
2. Alternatively, treat the workspace check as intended on LTS pushes and the red as expected — though the 1.43.x history suggests it isn't actionable there.

I found this while auditing release-branch CI runs, verified the run and step conclusions via the Actions API, and reproduced the failing job on the fork linked above. I used AI assistance (Claude) for the investigation and drafting; I've reviewed it and stand behind it.