Enforce tag-based CI approvals

CI pipelines are getting a new choke point — on purpose. The idea is simple: merging code no longer means shipping code. Teams are making production deployments start only from specific Git tags, then forcing a human approval before the deploy job can touch prod secrets or runners. Basically, they are turning “create release” into a separate, auditable act instead of letting every green commit flow straight through. (docs.github.com) ### Why use tags at all? A Git tag is a named pointer to one exact commit. That sounds small, but it changes the release model. A branch keeps moving. A tag is supposed to mark the exact revision you intend to ship — `v2.4.1`, say — and then stay there. GitLab’s protected tags are built around that idea: you can control who is allowed to create them and prevent accidental updates or deletion. (docs.gitlab.com) ### Why not just deploy from `main`? Because `main` answers “what passed CI most recently,” not “what did we explicitly approve for production?” Those are different questions. In a branch-driven flow, a harmless docs merge, a rushed hotfix, and a risky refactor all sit on the same conveyor belt. In a tag-driven flow, the team picks one exact commit, stamps it, and says: this is the release candidate. That separation is the whole point(docs.gitlab.com)f a vibe. (docs.gitlab.com) ### Where does the manual approval happen? Usually at the environment layer. GitHub Actions environments can require approval before a job proceeds, and the job will not start until the environment’s protection rules pass. GitLab does the same thing with deployment approvals on protected environments — deployments stay blocked until the required approvers sign off. Jenkins has long had the blunt version with the `input` step, which pa(docs.gitlab.com)ame control point. (docs.github.com) ### What does the pipeline usually look like? The common pattern is two-stage. First, every push or pull request builds, tests, and maybe publishes an image for staging. Second, only a protected tag like `v*` triggers the production workflow. That workflow points at the production environment, waits for approval, and then deploys the artifact tied to that tagged commit. The catch is that the (docs.github.com)upports immutable tags, and Docker’s docs also push image digests as the tamper-resistant reference. (docs.github.com) ### Why are people talking about this now? Because AI coding tools compress the time between idea and merge. That is useful, but it also raises the risk that code gets accepted faster than humans really reviewed it. A tag gate is a speed bump in the right place. It does not stop AI-written code from entering a repo. It stops unblessed code from quietly becoming a production release just because the default branch stayed green. That is less about distrusting AI than about restoring a clear handoff. (docs.github.com) ### Does this help with compliance too? Yes — and that is a big reason enterprises like it. A protected tag tells you who marked the release point. An environment approval tells you who authorized the deploy. The deployment record tells you when the production job actually ran. Put those together and you get a cleaner audit trail than “some commit on `main` eventually rolled out.” GitHub envi(docs.github.com)see prod credentials until the gate opens. (docs.github.com) ### What is the catch? Tags are only trustworthy if tag creation is locked down and the deployed artifact is immutable. If anyone can mint `v3.2.0`, or if `app:prod` can be overwritten later, the whole scheme turns into theater. Kubernetes will happily run whatever image reference you give it, so the discipline has to come from the release process — protected tags, protected environments, and immutable image references. (docs.gitlab.com) ### Bottom line This is not a new product or a single vendor launch. It is a release pattern solidifying across existing tooling. The shift is from “CI passed, ship it” to “tag it, approve it, then ship that exact thing” — which is exactly the kind of friction teams now want before production.