Publish a release only for a tag on a commit on main #17

Merged

GrumpyStraw merged 1 commit from tag-on-main into main

2026-10-13 19:35:31 +02:00

GrumpyStraw commented

2026-10-13 19:21:21 +02:00

Owner

Tags on main only

A v* tag published a release from whatever commit it pointed at. A tag pushed on a side branch by mistake would have built and published that branch as a release.

The "Work out the version" step now checks, for a tag, that the tagged commit is on main, before the version and changelog checks and before the build. The checkout fetches only the tagged commit, so the step first fetches the history of main (with --unshallow when the checkout is shallow), then runs git merge-base --is-ancestor HEAD FETCH_HEAD. It passes for the merge commit and for any older commit on main. When it fails, the job stops with:

Tag v0.2.0-side points at a00a5fc, which is not on main. Tag a commit on main.

The release job needs the build job, so nothing is published. Pushes to main skip this, and keep the shallow checkout.

HEAD is used instead of GITHUB_SHA, since it is the commit even for an annotated tag.

The workflow's header comment and the README's release paragraph mention the rule.

Checked

In a scratch copy of the repository, with a shallow checkout of one tag as in CI: v0.2.0 and v0.1.0 pass, and a tag on a commit on a side branch fails with the message above. With a full clone, v0.2.0 passes and the side-branch tag fails. The workflow file parses as YAML.

## Tags on main only A `v*` tag published a release from whatever commit it pointed at. A tag pushed on a side branch by mistake would have built and published that branch as a release. The "Work out the version" step now checks, for a tag, that the tagged commit is on `main`, before the version and changelog checks and before the build. The checkout fetches only the tagged commit, so the step first fetches the history of `main` (with `--unshallow` when the checkout is shallow), then runs `git merge-base --is-ancestor HEAD FETCH_HEAD`. It passes for the merge commit and for any older commit on `main`. When it fails, the job stops with: ``` Tag v0.2.0-side points at a00a5fc, which is not on main. Tag a commit on main. ``` The release job needs the build job, so nothing is published. Pushes to `main` skip this, and keep the shallow checkout. `HEAD` is used instead of `GITHUB_SHA`, since it is the commit even for an annotated tag. The workflow's header comment and the README's release paragraph mention the rule. ## Checked In a scratch copy of the repository, with a shallow checkout of one tag as in CI: `v0.2.0` and `v0.1.0` pass, and a tag on a commit on a side branch fails with the message above. With a full clone, `v0.2.0` passes and the side-branch tag fails. The workflow file parses as YAML.

GrumpyStraw added 1 commit

2026-10-13 19:21:21 +02:00

Publish a release only for a tag on a commit on main

Pull request checks / Lint and test (pull_request) Successful in 6m15s

Details

Build and release / Build the Flatpak (push) Failing after 5s

Details

Build and release / Publish the release (push) Has been skipped

Details

7b32cb4961

The tag build fetches the history of main and stops before building when the tagged commit
is not on it. A tag pushed on a side branch by mistake no longer builds or publishes a
release.

GrumpyStraw added the

Kind/Feature

label

2026-10-13 19:21:26 +02:00

GrumpyStraw self-assigned this

2026-10-13 19:21:26 +02:00

GrumpyStraw merged commit 19312d1611 into main

2026-10-13 19:35:31 +02:00

GrumpyStraw deleted branch tag-on-main

2026-10-13 19:35:31 +02:00

GrumpyStraw referenced this pull request from a commit

2026-10-13 19:35:32 +02:00