safe-global / safe-client-gateway / 36429054575

89%

push

github

feat(ci): add release-please as an opt-in release pipeline (#3490)

* feat(ci): add release-please as an opt-in release pipeline

Third of the four PRs splitting ci.yml into reusables plus callers. Purely additive: nothing is removed, and cutting a release by hand keeps working exactly as it does today, because ci.yml still owns `release: released` and still builds the release image.

`release-please.yml` triggers on a successful push-driven Staging run, so a release can only ever be cut from a commit staging actually validated — deployed, version-polled and smoke-tested. It keeps one rolling Release PR whose version and CHANGELOG come from the Conventional Commits since the last release. The repo is well placed for that: 59 of the last 60 commits on main follow the convention.

**Merging this makes a Release PR appear.** It will not merge itself — `auto_merge_release: false` — and merging it is exactly equivalent to cutting a release by hand today: it tags, publishes the GitHub Release, and `ci.yml` builds the image off `release: released` as it always has. So the team can ignore it, or adopt it, at its own pace. Nothing is forced by this PR.

`package.json` gains `"version": "1.125.0"`, matching the current latest release and what production serves, so the first Release PR proposes 1.126.0 rather than starting from zero. Nothing in `src/` reads that field; the version the service reports at `/about` comes from the VERSION build-arg, not from here.

One detail that is not cosmetic: the release MUST be created with the GitHub App token, which `_release.yml` does. A release created by `GITHUB_TOKEN` does not emit `release: published` — GitHub suppresses it to prevent workflow loops — so `production.yml` would never fire once it lands, and `linear-release.yml` depends on that event too.

`_release.yml` is byte-identical to safe-config-service's, except `release-type` defaults to `node` instead of `python`. Verified against that repo's current main, not ... (continued)

4462 of 5246 branches covered (85.06%)

Branch coverage included in aggregate %.

11391 of 12501 relevant lines covered (91.12%)

542.63 hits per line