Which strategy should I use for GitLab release-cli Deprecation in 18.0 Before Removal in 19.0?
Teams still using GitLab release-cli need to decide how to migrate release automation before GitLab 19.0 removes both release-cli and the release-keyword fallback path.
Blockers
- deprecated
- removed
- fallback path removed
- requires_version: capability/release-keyword → package/glab-1-58-0
- Lock-in via package/glab
- package/release-cli — EOL 2026-05-21
Who this is for
- enterprise
- small-team
Candidates
Migrate release keyword jobs to glab via the official cli image
GitLab documents that release-cli was deprecated in GitLab 18.0 and is planned for removal in 19.0. As of 2026-03-27, GitLab says jobs using the `release` keyword should move to `registry.gitlab.com/gitlab-org/cli:latest` and use GitLab CLI instead. GitLab also documents that the release-keyword path now requires `glab` `v1.58.0` or higher to avoid errors or warnings. GitLab's maintenance policy page lists GitLab 19.0 as scheduled for 2026-05-21, so the migration window is still open but short.
When to choose
Use this when you already rely on the GitLab `release` keyword and want the lowest-friction migration before 19.0. It is the default choice for small-team plus low-ops release pipelines because it keeps the same high-level job shape while replacing the deprecated toolchain.
Tradeoffs
Least disruptive path and aligned with GitLab's documented migration guidance, but it still requires runner images or installed CLI versions to meet the `glab` minimum. Pinning `cli:latest` reduces setup work but can introduce future CLI drift unless you later pin a specific tag.
Cautions
Do not assume the old automatic fallback will save outdated runners after 19.0; GitLab says that fallback is removed with release-cli. If you manually manage runner toolchains instead of using the official image, verify `glab` is at least `v1.58.0` before cutover.
Replace direct release-cli scripting with explicit glab release commands
GitLab states that release-cli is in maintenance mode, does not accept new features, and that new feature development happens in `glab`. As of 2026-03-27, this is the right path if your pipeline calls `release-cli` directly from `script` steps rather than only through the `release` keyword. GitLab CLI provides release subcommands and is the supported long-term interface. This avoids depending on the legacy shim behavior that disappears in 19.0.
When to choose
Use this when your release flow needs command-level control, custom scripting, or already shells out to `release-cli`. It is the better choice for enterprise or custom pipelines where you want explicit ownership of the release command path instead of depending on GitLab's keyword translation layer.
Tradeoffs
More explicit and future-proof than keeping release-cli wrappers, but it usually requires more pipeline edits than simply swapping the job image. Teams must map old release-cli invocations to `glab release` behavior and retest permissions, tag handling, and asset upload flows.
Cautions
GitLab's docs emphasize using GitLab CLI going forward, but you should still validate every scripted release operation in a non-production project before the 19.0 upgrade. For pricing or tier-specific feature availability, check official GitLab pricing docs because the deprecation pages do not make pricing the key decision factor.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for GitLab release-cli Deprecation in 18.0 Before Removal in 19.0?"