• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

safe-global / safe-client-gateway / 36429054575
89%

Build:
DEFAULT BRANCH: main
Ran 28 Sep 2026 01:32PM UTC
Jobs 2
Files 1033
Run time 3min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

28 Sep 2026 01:29PM UTC coverage: 89.328% (-0.02%) from 89.35%
36429054575

push

github

web-flow
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

Coverage Regressions

Lines Coverage ∆ File
1
86.67
-5.0% src/modules/notifications/routes/v1/notifications.controller.ts
1
83.96
-0.94% src/modules/relay/domain/relayers/no-fee-campaign.relayer.ts
Jobs
ID Job ID Ran Files Coverage
1 run-integration-tests - 36429054575.1 28 Sep 2026 01:36PM UTC 1033
64.55
GitHub Action Run
2 run-unit-tests - 36429054575.2 28 Sep 2026 01:32PM UTC 1033
66.81
GitHub Action Run
Source Files on build 36429054575
  • Tree
  • List 1033
  • Changed 3
  • Source Changed 0
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #36429054575
  • 6185768f on github
  • Prev Build on main (#36404042940)
  • Next Build on main (#36442334892)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc