Default download_url expects tarballs that most repos no longer publish

[piontec]

Part of giantswarm/giantswarm#37347 — Lack of schema testing in github-workflows lets bugs pass

Summary

The default download_url encodes a release-asset naming convention that most Giant Swarm repos have already stopped producing. Every repo that hits that transition inherits a silent 404 at its next release, and finds out from its downstream consumers.

Default today

https://github.com/giantswarm/${binary}/releases/download/v${version}/${binary}-v${version}-linux-amd64.tar.gz

Those <repo>-v<version>-<platform>.tar.gz assets are not produced by CircleCI/architect. They come from giantswarm/github-workflows, create-release.yaml, job create_and_upload_build_artifacts — which only runs when the calling repo passes build-release-artifacts: true.

The chore: align files according to platform standards template drops that input from zz_generated.create_release.yaml. Any repo it touches quietly stops publishing tarballs at its next release, while architect 8.x/9.x publishes raw binaries (<repo>-linux-amd64 + sigstore .bundle) instead.

repo	build-release-artifacts	align-files PR that dropped it	released since?
giantswarm/schemalint	absent	giantswarm/schemalint#319 (2026-07-29)	yes → broke at v2.6.2
giantswarm/gitsemver	absent	giantswarm/gitsemver#260 (2026-06-11)	not yet
giantswarm/architect	absent	giantswarm/architect#1325 (2026-06-17)	yes, v8.3.0 is raw-binary-only
giantswarm/helm-values-gen	true	—	—
giantswarm/apptestctl	true	—	—

What it cost once already

schemalint/actions/verify-helm-schema relied on this default. v2.6.2's release had no tarball, so every repo consuming giantswarm/github-workflows/.github/workflows/json-schema-validation.yaml@main — i.e. every cluster app repo — failed within a minute of Renovate bumping the pin there:

download URL:  https://github.com/giantswarm/schemalint/releases/download/v2.6.2/schemalint-v2.6.2-linux-amd64.tar.gz
##[error]Unexpected HTTP response: 404

(cluster-aks run 30920183465; fixed in schemalint v2.6.3 by setting an explicit download_url.)

Note the failure is invisible until a release happens. Nothing in the release PR can catch it, because the release does not exist yet when the version is bumped.

Suggestions, in order of usefulness

1. Better error message — no breaking change, worth doing regardless. On a 404, list the assets that do exist on that release (one extra API call) and say so:

   Asset "schemalint-v2.6.2-linux-amd64.tar.gz" not found on release v2.6.2.
   Available: schemalint-linux-amd64, schemalint-linux-amd64.bundle, ...
   Hint: this release publishes raw binaries. Set download_url explicitly.
   

   This turns a 20-minute investigation into a 5-second read, in every consumer repo at once.

2. Flip the default to the raw binary in v5.0.0 — .../v${version}/${binary}-linux-amd64 — since that is what architect 8.x/9.x actually produces. Breaking, so it needs a major and a migration note for the repos that still pass build-release-artifacts: true.

3. Not this repo's problem, but the actual root cause and worth flagging to whoever owns it: the align-files template removes tarball production without updating the consumers that request tarballs by name. Either it should keep build-release-artifacts: true, or the migration should include a sweep for -v${version}-linux-amd64.tar.gz download URLs.

Related

• feat(ci): self-test the verify-helm-schema action schemalint#338 — self-test so a release with mismatched assets is caught in the owning repo.
• feat(ci): self-test json-schema-validation against a fixture chart github-workflows#262 — self-test so a bad action pin cannot merge and go live org-wide.
• fix(ci): install gitsemver from its raw release binary github-workflows#263 — the same latent bug found in gitsemver, pinned in 4 places in the org's release workflows.