syntaqxA pushed annotated tag starts the workflows that filter its tags: pushing cli-v0.3.5 and then cli-v0.3.6 (alone, git push g1t cli-v0.3.6) to flagon-io/g1t started no CLI release run from .g1t/workflows/cli-release.yml (push: tags: ["cli-v*"]), while cli-v0.3.3 and cli-v0.3.4 had started runs #4 and #5. Those two were lightweight tags; 0.3.5 and 0.3.6 are annotated. After a push, repos checks each pushed ref against where the store actually has it (the store can refuse one ref and accept another) and announces only refs that moved; for a tag it compared the commit the tag reads back as with the hash the push named, which for an annotated tag is the tag object (accae3e8), never the commit it leads to (42a29574), so the tag was taken as refused and no git.push event was published: Actions never heard of it, and nothing about the tag's commit already having run on main was involved. That check now lives in pushed.rs (pushed_to): a branch must be at the commit pushed, as before; a tag whose commit differs from what the push named is taken as pushed unless what it named is itself a commit (then the store left a lightweight tag elsewhere), and a tag is announced at the commit it leads to, as git.push says its after is, so the run is at that commit, as GitHub runs a tag push at the tagged commit. A tag the store cannot read back is still taken as pushed. Deploy: repos. Checked: cargo test -p g1t-repos (367, with new tests for an annotated tag, a lightweight one the store left elsewhere and branches); cargo check -p g1t-repos --target wasm32-unknown-unknown.4e63b3fHistory
