Rendered at 17:50:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
1718627440 18 hours ago [-]
You can kind of arrive at the same solution, without actually thinking about all this, by just merging into a release branch when making a release.
lijok 20 hours ago [-]
Or commit a file to main that represents a release and build your automations off that
gouggoug 19 hours ago [-]
One step further: use `git tag` for what it's for: tagging a given commit with an immutable reference (say, a version number like `v1.0.23`), and generate and publish "build artifacts" (`my-application-v1.0.23.tar.gz`, `my-application-v1.0.23` binary, `my-application-v1.0.23.tar.gz` helm chart, `my-application-v1.0.23` container image, `my-application-v1.0.23` ... whatever binary artifact)
dgrin91 17 hours ago [-]
A quirk here- tags are not actually immutable in git. I agree with the premise, and use tags myself for releases, but if you rely on them being immutable then you have loaded a footgun
gouggoug 17 hours ago [-]
true — they only are immutable by convention and because the git command refuses by default to modify/push an existing tag.
teamolHuang 12 hours ago [-]
Complicated and unintuitive.
Our company has a few dozens of different project repos. I just created a repo for storing deploy manifests (versions, etc. for every repos of a product), and then let our automation pipeline commit the manifest. Simple to follow and no source-unrelated crap in source repos.
unsloppable 18 hours ago [-]
Cool and clever.
One question: what do you use your old refs for?
We just delete them when we get too many.
Imzadi72 16 hours ago [-]
Agreed. I get that you want to know the last few releases and maybe even all the releases to production. But all the releases to staging as well!? What possible use-case do you want to solve which version you released two years ago to staging?
I've stopped reading the article actually before the actual solution.
Our company has a few dozens of different project repos. I just created a repo for storing deploy manifests (versions, etc. for every repos of a product), and then let our automation pipeline commit the manifest. Simple to follow and no source-unrelated crap in source repos.
One question: what do you use your old refs for?
We just delete them when we get too many.
I've stopped reading the article actually before the actual solution.