mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-09-23 23:32:05 +00:00
YoursFunny
f8796913e5
Pushing master and a release tag fires two workflow runs, and `should-build` exists to keep only one of them building: a branch run skips when its commit is already tagged. It never worked — `actions/checkout` does not fetch tags (`fetch-tags` defaults to false, and `fetch-depth` does not imply it), so `git tag --points-at "$GITHUB_SHA"` came up empty and the master run built the same commit the tag run was building: two ~6 minute docker builds pushing the same image, for v1.9.0 and again for v1.9.1. The check step now fetches the tags itself, immediately before deciding, so the view is as fresh as it can be. Reproduced and fixed against this repo: a clone made the way the action makes it (`--no-tags`) reports "NO TAG -> build=true (duplicate build!)" for the tagged v1.9.1 commit, and the same clone after the step's `git fetch --tags --force origin` reports "tag(s): v1.9.1 -> build=false (skip)". A tag pushed *after* the branch run started cannot be anticipated, so the release flow is documented as one push (`git push origin master vX.Y.Z`) in both the workflow and AGENTS.md; pushing master first is exactly what made today's pair build twice. `cargo fmt --check`, `clippy`, the test suite and the workflow's YAML parse are all clean (workflow/docs only, no Rust changes).