> GitHub themselves do it with GitHub Actions

That makes sense, so does doing releases by using tags, why would that make you uncomfortable?

What doesn't make sense, is creating a completely new language/framework/package manager and decide to place the package registry burden on someone else.

▲

formerly_proven 3 hours ago | parent [-]

> That makes sense, so does doing releases by using tags, why would that make you uncomfortable?

Tags are not immutable.

▲

embedding-shape 3 hours ago | parent [-]

Are you confusing tags with branches? Git tags for all intents and purposes are immutable. If you have a tag in your local repository that was pulled down from another remote, and the remote changes the tag and you update your local repository, it'll reject the incoming tag.

It's true they're both refs inside git, but git literally treats them as "shouldn't move", unlike branches. They're not immutable in the technical sense, so I guess you're technically right. But they're not used the same way as branches, and the tooling won't like that either.

	▲	bspammer 2 hours ago \| parent \| next [-]
		That's irrelevant in the context of GitHub Actions: CI runners clone the repo fresh every run. If someone gets write access to a widely used action, they can force push all tags to point to a malicious commit. This is even in GitHub's docs: https://docs.github.com/en/actions/reference/security/secure... > Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
	▲	growse 2 hours ago \| parent \| prev [-]
		If you're in (for example) a CI context and do a git checkout @tag, there's no guarantee that you'll get the same content as the last time you fetched that tag. Tags are not immutable.