Release pipeline

Maintainer workflow for versioning and publishing the A2C VS Code extension (a2c-vscode-extension).

Normative policy: ADR-0009 (supersedes ADR-0004).

Prerequisites

• Protected refs: master, develop, release/*, tags v*.*.* on GitLab
• VERSION file at repo root holds the current semver (version source of truth)
• package.json version kept in lockstep with VERSION
• Root CHANGELOG.md required — ADR-0002
• scripts/bump_release.py, scripts/verify_release_version.py, scripts/verify_release_ready.py, scripts/tag_release.py, scripts/promote_release_artifact.py
• bundled-cli.manifest.json — pinned a2c-workflow CLI version for bundled binaries

Branch and CI profiles (ADR-0009)

Ref	Role	CI profile
Feature branch or develop	Day-to-day work (develop is optional; CI treats it like a feature branch)	Development CI (full)
release/X.Y.Z	Release bump and qualification	Development CI (release gates only; no screenshots/docs)
Tag vX.Y.Z	Canonical release marker	Release CI (release:verify, release:promote)
master	Integrated history	Master CI (light, non-gating: master:integration-record)

Normal development (untagged → master)

1. Work on a feature branch or develop
2. Wait for green Development CI
3. Fast-forward merge to master (untagged, code_clean)

Multi-developer: feature → Development CI → ff-merge master Single-developer: feature or develop → Development CI → ff-merge master

Release steps (release/X.Y.Z → tag → master)

1. Land features; ff-merge code_clean commits to master as usual

2. Update bundled-cli.manifest.json → cli_version when pairing with a new a2c-workflow tag; wait for upstream tag pipeline binaries

3. Create release branch from master:

   git checkout master && git pull origin master
   git checkout -b release/X.Y.Z

4. Run python scripts/bump_release.py on the release branch

5. Push release/X.Y.Z

6. Wait for green Development CI on the release branch (mandatory gate):

   python scripts/verify_release_ready.py --ref release/X.Y.Z --wait

7. Tag and push using the gated helper:

   python scripts/tag_release.py --wait --ref release/X.Y.Z

8. Wait for green Release CI on the tag (release:verify + release:promote)

9. Fast-forward master from the release branch:

   git checkout master && git merge --ff-only release/X.Y.Z && git push origin master

If Release CI fails: fix on release/X.Y.Z, rerun Development CI, move the tag if needed (git tag -f per protected-tag policy), push tag again, then retry step 8–9.

CI job mapping

Development CI (feature, develop, release/*)

Job	On develop/MR	On release/*
lint, typecheck, test:unit	yes	yes
package:fetch-cli, package:vsix, package:vsix-smoke	yes	yes
test:integration:screenshots, docs:build, pages	yes	no
trigger:docs-portal	yes	no

verify_release_ready.py requires: lint, typecheck, test:unit, package:fetch-cli, package:vsix, package:vsix-smoke.

Release CI (tags v*.*.*)

Job	Purpose
release:verify	Tag matches VERSION and package.json
release:promote	Promote package:vsix artifact from release/X.Y.Z pipeline at tagged SHA

Master CI (light, non-gating)

Job	Purpose
master:integration-record	Audit log on master pushes; does not imply code_clean or released

Local dry-run

python scripts/bump_release.py --dry-run
python scripts/verify_release_ready.py --ref release/0.2.2
python scripts/tag_release.py --dry-run --ref release/0.2.2

Consumer adoption

Teams adopting a specific extension release should record the version in their workflow ADR or internal release notes.