Release pipeline: macOS assets never published (installer 404s since v0.37.2) and releases stalled at v0.40.1 while main is v1.31.12

[trakhimenok]

Summary

Two related release-pipeline failures:

1. macOS installs are impossible via the documented curl | sh path — the darwin assets are never published, so the installer 404s.
2. Releases are stalled at v0.40.1 (2026-03-04) while main is at v1.31.12. Even Linux and Windows users are ~11 minor versions behind.

Every release.yml run since v0.37.2 has failed.

1. macOS: installer 404s because darwin assets are never uploaded

Reproduce on macOS (darwin/arm64):

$ curl -fsSL https://ingitdb.com/install/get-cli | sh
ingitdb v0.40.1 (darwin/arm64)
  archive: https://github.com/ingitdb/ingitdb-cli/releases/download/v0.40.1/ingitdb_0.40.1_darwin_arm64.tar.gz
curl: (56) The requested URL returned error: 404
error: download failed

The installer is not at fault. It computes the correct name — goreleaser-homebrew.yaml declares
name_template: {{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }} over goos: [darwin],
goarch: [amd64, arm64], which is exactly ingitdb_0.40.1_darwin_arm64.tar.gz. The asset simply
isn't there.

Assets actually published on v0.40.1:

checksums-windows.txt
checksums.txt
ingitdb_0.40.1_linux_amd64.tar.gz
ingitdb_0.40.1_linux_arm64.tar.gz
ingitdb_0.40.1_windows_amd64.zip

No darwin. No checksums-darwin.txt (which goreleaser-homebrew.yaml declares as its
checksum.name_template) — consistent with that goreleaser config never completing.

It's a regression

Count of darwin assets per release:

Release	Date	darwin assets
v0.22.10	2026-02-24	3
v0.24.1	2026-02-24	3
v0.37.2	2026-03-03	0
v0.40.1	2026-03-04	0

Root cause

Darwin is built by the publish-homebrew job (runs-on: macos-latest, --config .github/goreleaser-homebrew.yaml), not by goreleaser-linux.yaml. That job fails, so linux/windows assets upload while darwin silently doesn't:

Run 22672466449 (the v0.40.1 release, 2026-03-04):

success   Build Linux, AUR, Create Release
failure   Publish to Homebrew          <-- darwin never uploads
success   Publish to Snapcraft
failure   Build Windows, WinGet, Scoop, Chocolatey
success   Deploy to Cloud Run

Because build-linux creates the release and succeeds, the release is published looking healthy while missing an entire platform. Worth considering whether a partial release should be marked draft/prerelease rather than published.

I could not retrieve the failure logs to pin the exact cause — GitHub has expired them (HTTP 410). Given goreleaser-homebrew.yaml has a notarize.macos block gated on isEnvSet "MACOS_SIGN_P12", the signing/notarization secrets are the first place I'd look.

2. Releases stalled since March

$ gh release list --repo ingitdb/ingitdb-cli --limit 5
v0.40.1   Latest   2026-03-04
v0.37.2            2026-03-03
v0.24.1            2026-02-24
v0.22.10           2026-02-24
v0.22.6            2026-02-23

Meanwhile git describe --tags on main reports v1.31.12.

The most recent release attempt, run 27357782836 (2026-06-11), failed in 30s at the first job:

failure   Build Linux, AUR, Create Release
skipped   Build Windows, WinGet, Scoop, Chocolatey
skipped   Publish to Snapcraft
skipped   Publish to Homebrew

So curl | sh currently serves a 4-month-old binary to Linux/Windows and nothing at all to macOS. Logs for this run have also expired (HTTP 410) — a shorter feedback loop or a failure notification would help here, since the logs outlive neither the problem nor the investigation.

Suggested fixes

1. Fix publish-homebrew so darwin assets upload again (check the MACOS_SIGN_P12 / NOTARIZE_* secrets first).
2. Fail the release loudly when a platform is missing — e.g. don't publish (or mark prerelease) unless every expected asset uploaded. A green release missing macOS is worse than a failed one, because the installer's 404 is the first anyone hears of it.
3. Cut a release from v1.31.x once the pipeline is green.
4. Consider a scheduled smoke test that runs the published installer on each OS against the latest release — this bug is invisible from inside CI but immediate to any user.

Environment

Found while installing the CLI to author an inGitDB-backed dataset (bots-go-framework/can-i-use). Worked around by building from source (go build ./cmd/ingitdb at v1.31.12), which works fine — list collections and select --from both behave.