|
| 1 | +# Release Automation |
| 2 | + |
| 3 | +This repository uses **semantic-release** + GitHub Actions to build, test, tag, create GitHub releases, and publish to npm. |
| 4 | + |
| 5 | +## What happens on a release run |
| 6 | + |
| 7 | +The release workflow is [.github/workflows/release.yml](.github/workflows/release.yml). |
| 8 | + |
| 9 | +1. **Tests run first** (unit + integration against Camunda 8 via Docker Compose). This job is copied from the test workflow so release runs are gated on the same checks. |
| 10 | +2. If tests pass, the workflow runs `npx semantic-release`. |
| 11 | +3. `semantic-release`: |
| 12 | + - determines the next version from commit messages (Conventional Commits) |
| 13 | + - generates release notes |
| 14 | + - **builds** the package (`npm run build`) |
| 15 | + - publishes to npm |
| 16 | + - creates a GitHub release + comments on included issues/PRs |
| 17 | + |
| 18 | +Release configuration lives in [.releaserc.json](.releaserc.json). |
| 19 | + |
| 20 | +## Branch and channel strategy |
| 21 | + |
| 22 | +We publish two “streams”: |
| 23 | + |
| 24 | +- **Alpha (prerelease)**: from branch `main` |
| 25 | + - published to npm under the `alpha` dist-tag (so users install via `npm i @camunda8/cli@alpha`) |
| 26 | + - versions look like `2.0.0-alpha.2` |
| 27 | + |
| 28 | +- **Stable (latest)**: from branch `release` |
| 29 | + - published to npm under the default `latest` dist-tag |
| 30 | + - versions look like `2.0.0` |
| 31 | + |
| 32 | +This is controlled by the `branches` setting in [.releaserc.json](.releaserc.json). |
| 33 | + |
| 34 | +## npm publishing and OIDC |
| 35 | + |
| 36 | +The release workflow is intended to publish using GitHub Actions **OIDC** (no long-lived npm token stored in GitHub). |
| 37 | + |
| 38 | +- The workflow requests `id-token: write` permissions. |
| 39 | +- npm must be configured to trust this GitHub repository for OIDC publishing. |
| 40 | +- The publish step uses provenance (`--provenance` / `NPM_CONFIG_PROVENANCE=true`). |
| 41 | + |
| 42 | +## What files get published |
| 43 | + |
| 44 | +npm decides what goes into the published tarball. |
| 45 | + |
| 46 | +In this repo, the `files` field in [package.json](package.json) limits the published contents to: |
| 47 | + |
| 48 | +- `dist/` |
| 49 | +- `README.md` |
| 50 | +- `LICENSE` |
| 51 | + |
| 52 | +(Plus `package.json` itself and npm’s standard always-included metadata files.) |
| 53 | + |
| 54 | +## Commit message requirements (semantic-release) |
| 55 | + |
| 56 | +semantic-release only creates a new release when there are commits that imply a version bump. |
| 57 | + |
| 58 | +Examples: |
| 59 | + |
| 60 | +- `fix: ...` → patch |
| 61 | +- `feat: ...` → minor |
| 62 | +- `feat!: ...` or `BREAKING CHANGE: ...` → major |
| 63 | + |
| 64 | +If you merge commits that don’t follow Conventional Commits, semantic-release may do **no release**. |
| 65 | + |
| 66 | +--- |
| 67 | + |
| 68 | +# Maintainer Procedures |
| 69 | + |
| 70 | +## Procedure: Release an alpha version (from `main`) |
| 71 | + |
| 72 | +This is the normal day-to-day prerelease flow. |
| 73 | + |
| 74 | +1. Ensure your changes are merged to `main` with Conventional Commit messages. |
| 75 | +2. Push to `main` (merging a PR to `main` is enough). |
| 76 | +3. Verify GitHub Actions: |
| 77 | + - Go to Actions → **Release** workflow |
| 78 | + - Confirm the run triggered on `main` completed successfully |
| 79 | +4. Verify artifacts: |
| 80 | + - npm: check that a new version exists under the **alpha** dist-tag |
| 81 | + - Example install: `npm i -g @camunda8/cli@alpha` |
| 82 | + - GitHub: confirm a new release + tag were created (tag format is `vX.Y.Z[-prerelease]`) |
| 83 | + |
| 84 | +If the workflow says “no release”: |
| 85 | + |
| 86 | +- Confirm at least one commit since the last tag uses `fix:`, `feat:`, or contains a breaking change marker. |
| 87 | + |
| 88 | +### One-time bootstrap (only if the package does not exist on npm yet) |
| 89 | + |
| 90 | +If npm OIDC requires the package to already exist, you can do a one-time manual alpha publish to create it. |
| 91 | + |
| 92 | +1. Update version + tag: |
| 93 | + - `git checkout main && git pull --ff-only` |
| 94 | + - `npm version 2.0.0-alpha.1 -m "chore(release): %s"` |
| 95 | +2. Build and publish: |
| 96 | + - `npm ci` |
| 97 | + - `npm run build` |
| 98 | + - `npm publish --tag alpha --access public` |
| 99 | +3. Push the commit + tag so semantic-release has the correct baseline: |
| 100 | + - `git push origin main --follow-tags` |
| 101 | + |
| 102 | +After this bootstrap, prefer the automated workflow for subsequent alpha releases. |
| 103 | + |
| 104 | +## Procedure: Release a stable version (from `release`) |
| 105 | + |
| 106 | +Stable releases are cut by updating the `release` branch. |
| 107 | + |
| 108 | +1. Decide what goes into the stable release. |
| 109 | + - Typical approach: fast-forward `release` to the desired commit from `main`. |
| 110 | +2. Update `release` locally: |
| 111 | + - `git fetch origin` |
| 112 | + - `git checkout release` |
| 113 | + - `git pull --ff-only` |
| 114 | + - Merge the desired commits from `main`: |
| 115 | + - Option A (recommended when releasing everything currently in `main`): |
| 116 | + - `git merge --ff-only origin/main` |
| 117 | + - Option B (selective): |
| 118 | + - `git cherry-pick <sha> ...` |
| 119 | +3. Push `release`: |
| 120 | + - `git push origin release` |
| 121 | +4. Verify GitHub Actions: |
| 122 | + - Go to Actions → **Release** workflow |
| 123 | + - Confirm the run triggered on `release` completed successfully |
| 124 | +5. Verify artifacts: |
| 125 | + - npm: the new version should be on the **latest** dist-tag (default) |
| 126 | + - Example install: `npm i -g @camunda8/cli` |
| 127 | + - GitHub: confirm a release + tag were created |
| 128 | + |
| 129 | +If you need to re-run without changing commits, you can use **Actions → Release → Run workflow** (workflow_dispatch), but note that semantic-release will still only publish if there are release-worthy commits since the last tag. |
0 commit comments