The install guide tells people to curl
.../releases/latest/download/<file>
which is a GitHub URL shape. GitLab's equivalent is
/-/releases/permalink/latest/downloads/<path>
but it only resolves for assets that declare direct_asset_path, and the
release job was creating plain links to the package registry. Those carry
the tag in the URL, so they can never be a "latest" link.
Each asset now also declares /binaries/<file>, which is what the docs will
point at. The path is load-bearing: changing it breaks a documented install
command.
Ports .github/workflows/release.yml after the GitHub account was suspended.
Same shape: tag-driven, amd64 and arm64, SOURCE_DATE_EPOCH for reproducible
tarballs, and the same refusal to release a tag that is not an ancestor of
the default branch.
The publishing half had to change. There is no `gh release`, so the
tarballs go to the project's generic package registry and the Release is
created with release-cli pointing at them. The install guide sends people
straight at release asset URLs, so uploading before creating the Release is
deliberate: a Release whose assets 404 is worse than no Release.
The Actions workflow stays in the tree as the reference.
jcoffey-dev