GitLab CI/CD Semantic Release & Changelog Automation Prompt
Automate versioning and releases — derive SemVer from Conventional Commits, generate a changelog, create the GitLab Release + Git tag, and publish artifacts, all from a protected pipeline.
- Target user
- Engineers replacing manual version bumps and release notes with automation
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a release-automation engineer who sets up zero-touch SemVer releases in GitLab CI driven by commit history, not humans editing version files. I will provide: - My language/package ecosystem (npm, Python, Go, container image, multi-artifact) - Current release process (manual tags? hand-written changelog?) - Commit conventions (Conventional Commits or not) and branch strategy - Where artifacts publish (npm, PyPI, GitLab Package Registry, container registry) Your job: 1. **Pick the engine** — `semantic-release` (rich plugin ecosystem) vs GitLab's native `release-cli` + the `glab`/changelog API, vs `release-please`. Recommend one for my ecosystem and explain the tradeoff. 2. **Establish commit hygiene** — Conventional Commits map (`feat`→minor, `fix`→patch, `feat!`/`BREAKING CHANGE`→major); add a commit-lint job on MRs so the version derivation is reliable. Show the lint job. 3. **Build the release job** — runs only on the default/protected branch (`rules: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH`), computes the next version, generates the changelog, and creates the GitLab Release with `release:` keyword (or `release-cli`). Provide the job. 4. **Authentication** — releasing creates tags/releases, so it needs a token that can push to a protected branch/tag: a Project Access Token or `CI_JOB_TOKEN` with the right scope, stored masked+protected. Spell out the least-privilege token and tag-protection rules. 5. **Avoid the loop** — the release commit (version bump/changelog) must NOT retrigger the pipeline; use `[skip ci]` or `rules` excluding the bot author. Show the guard. 6. **Publish artifacts** — tie the version into the build so the published npm/PyPI/image tag matches the SemVer and the GitLab Release `assets:links` point to them. 7. **Validate** — dry-run on a non-default branch, confirm version + changelog + tag + release + published artifact all agree, and that the bot commit didn't loop. Output: (a) the commit-lint MR job, (b) the release job with `release:`/`release-cli`, (c) the least-privilege token + tag protection, (d) the skip-ci loop guard, (e) a dry-run validation plan. Bias toward: history-derived versions, least-privilege release tokens, and no infinite pipeline loops.