Update the release script to not create tags on build

[krlvi]

It appears that our current process is disruptive for community packaging efforts:
#11525 (comment)

Because the tag is used in the version bumping, we need to think this through a bit.

[Byron]

Just for completeness, here is where tags are created:

gitbutler/.github/workflows/publish.yaml

Lines 415 to 438 in 742ffbe

	- name: Create git tag
	shell: bash
	env:
	TAG_NAME: '${{ needs.build-tauri.outputs.channel }}/${{ needs.publish-tauri.outputs.version }}'
	run: |
	function tag_exists() {
	git tag --list | grep -q "^$1$"
	}
	function fetch_tag() {
	git fetch origin "refs/tags/$1:refs/tags/$1"
	}
	function delete_tag() {
	git push --delete origin "$1"
	}
	function create_tag() {
	git tag --force "$1"
	git push --tags
	}
	fetch_tag "$TAG_NAME" || true
	if tag_exists "$TAG_NAME"; then
	delete_tag "$TAG_NAME"
	fi
	create_tag "$TAG_NAME"

What about creating pending-release/<version> for release tags? Then these wouldn't be picked up until you rename them, while also getting a template from CI.
Of course, it's also easy to not create tags for release builds at all, but I'd find it helpful to see what CI saw.

Edit: Additionally, I think nightly builds should create their tags unchanged as they are fully automated, there is no chance they drift.

[slarse]

I don't think it's a good idea to build any system around re-tagging, even if the tags aren't deemed important. The man page for git-tag even has a section about the "insane thing" (re-tagging). If the publish script attempts to re-tag, it should fail.

But I also really don't see the need. If a build is tagged and there ends up being a problem with it, just bump the version again? The botched build doesn't need to be published on the website either. It can just exist as a tag, which at worst would be yanked after the next tag is pushed. Or, more typically, just left to sit there forever.

I propose we just edit the publish script s.t. it cannot re-tag, and then if there's a release that has issues, just bump the version number again and make a new release.

[slarse]

Put up a PR that just removes the "move code". I think that regardless of how you ultimately want to control tagging, that should go in, as re-tagging is a bit of a nuisance in a public repository.

And just getting of my high-horse a little bit, I've of course done the naughty myself in the past :). Let's be better than past me...

[Byron]

Yes, I agree and also think that any 'delayed tagging' shenanigans is an orthogonal problem that can also be completely bypassed if it's fine to have non-consecutive version numbers (i.e. some might never see the day of light due to last minute changes).

[krlvi]

The way I was thinking of approaching this was going to be to make the part of the system where we perform "publish release" to create the tag.

[Byron]

That sounds like it will be some web-backend work. Does it make sense to get a version of this PR merged?

[slarse]

I think the nightly jobs will still need the full automation, like @Byron said. We can simply remove the re-tagging logic and add a skip condition if the channel is release, if we want more control over the release tags specifically.