Review found that the GitHub Actions cache layer cost more than it
saved. Measured on ubuntu-latest, same job, same version:
cold: download + checksum + cosign + extract 0.93 s
cache hit: restore the 24 MB entry 1.28 s
first run also pays a save +2.26 s
It is slower than a download in every configuration measured, because a
GitHub-hosted runner reaches the release CDN in about 0.4 s for a 15 MB
archive, and the cached entry is the larger extracted directory.
It also skipped the sha256 and cosign verification on a hit, which is
the control it was supposed to protect, and the only case where it wins
on time is when cosign is installed, which is exactly the case where
skipping is wrong. It cost 875 KB (+120%) of dist/index.js for every
user and 24 MB of repository cache quota per version and platform.
The restore and save wrappers were also dead code: @actions/cache
catches everything except ValidationError internally, so the try/catch
and the ReserveCacheError classification could never run.
What remains is the runner tool cache lookup, which is what #476 asked
for, and the distribution-keyed tool name that stops a Pro binary being
returned for an OSS install.
The tool cache test asserted that two installs return the same path, but
that path is a pure function of the tool, version and architecture: it
passed even with the tool cache wiped between the calls. It now asserts
that the second install reports a tool cache hit and does not download,
and it was verified to fail when the lookup is removed.
Co-authored-by: timbretimber <105982513+timbretimber@users.noreply.github.com>
Co-authored-by: Akkuman <akkumans@qq.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4eaf86fa-a85b-41f6-8763-612acc1ccc39
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Look for GoReleaser in the runner tool cache before a download. This
makes a second use of the action in the same job, or any job on a
self-hosted runner, install immediately.
Add an opt-in `cache-binary` input that also stores the binary in the
GitHub Actions cache. When it hits, the action does not download the
release archive, the checksums and the signature bundle again. Cache
errors are not fatal and fall back to a download.
The runner tool cache entry is now keyed by distribution, so a Pro
binary is no longer returned for an OSS install of the same version.
Closes#476
Co-authored-by: timbretimber <105982513+timbretimber@users.noreply.github.com>
Co-authored-by: Akkuman <akkumans@qq.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
* fix(nightly): pick latest nightly by published_at
GitHub's /releases endpoint is not reliably ordered by published_at,
so resolveNightly could pick an older nightly than the most recent
one. Filter, sort by published_at desc, and take the first.
* test(nightly): add regression coverage for release ordering
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Both goreleaser and goreleaser-pro now publish nightly releases as
vX.Y.Z-<sha>-nightly, so the action no longer needs to special-case
or fall back to the moving 'nightly' tag.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: resolve nightly to latest vX.Y.Z-<sha>-nightly release
Query GitHub releases API to resolve the 'nightly' version input to the
latest immutable nightly tag, replacing the moving 'nightly' tag that is
being removed for supply-chain hardening.
Refs goreleaser/goreleaser#6550
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: keep legacy 'nightly' tag working during transition
Fall back to the moving 'nightly' tag when no immutable
vX.Y.Z-<sha>-nightly release is found, so the action keeps working
between this release and the goreleaser nightly switchover.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* test: assert isNightlyTag accepts legacy fallback
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: accept nightly tags without 'v' prefix
goreleaser-pro publishes nightly releases as e.g. 2.16.0-eaeb08c50-nightly
(no 'v' prefix). Make the nightly tag regex tolerate either form, and
split the integration tests so OSS asserts the legacy fallback while
Pro asserts the new <version>-<sha>-nightly format.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Revert "fix: accept nightly tags without 'v' prefix"
The missing 'v' prefix on the goreleaser-pro nightly was a release
mistake; new nightlies will keep the 'v' prefix.
This reverts commit 7673f7f.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* ci: pass GITHUB_TOKEN to tests
The new nightly resolution hits api.github.com/repos/.../releases,
which is rate-limited for unauthenticated requests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* docs: note GITHUB_TOKEN need for nightly resolution
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Resolves the GoReleaser version from a file. Currently supports the
asdf/mise `.tool-versions` format; resolved value takes precedence
over the `version` input.
# .tool-versions
goreleaser 2.13.0
- uses: goreleaser/goreleaser-action@v7
with:
version-file: .tool-versions
args: release --clean
Path is resolved relative to `workdir` unless absolute. Bare semvers
are auto-prefixed with `v`; constraint expressions and `latest` are
returned as-is. Multiple fallback versions per asdf convention are
accepted but only the first is used.
Refs #541Closes#542
Co-authored-by: Anthony Couvreur <22034450+acouvreur@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add install tests pinned to versions that exercise every release era so
we don't regress the graceful-skip path for releases that pre-date the
cosign v3 sigstore bundle:
- v0.182.0 pre-checksums-signing
- v1.26.2 cosign v2 detached .sig only
- v2.12.4 last release before sigstore bundles
- v2.13.0 first release with sigstore bundle (minimum verifiable)
- v2.15.3 recent release with sigstore bundle
Plus an explicit verifyChecksum integration test that installs v2.12.4
with cosign in PATH to confirm the cosign step is skipped (not failed)
when the sigstore bundle is absent.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
GoReleaser v2.13.0 was the first release to ship the cosign v3
sigstore-bundle 'checksums.txt.sigstore.json' alongside the archive.
Earlier releases only publish a cosign v2 detached '.sig', which the
action's verifier does not understand and silently skips.
Drop '~> 1.26' / '~> 2.6' / 'v0.182.0' / '~> v1' from the matrix and
the install tests; pin '~> 2.13' as the minimum-supported version we
actively exercise in CI. Document v2.13.0 as the minimum cosign-
verifiable version in the README.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: verify release checksum and cosign signature
Download checksums.txt for the release and verify the SHA-256 of the
downloaded archive against it. When cosign is available in PATH, also
download checksums.txt.sigstore.json and verify the signature against
the goreleaser/goreleaser-pro release workflow identity. Both steps
degrade gracefully (with a warning) when the corresponding artifacts
or tooling are missing.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* test: use install() for checksum e2e tests
Drop the http-client download helper from verifyChecksum integration
tests; call goreleaser.install() instead so the test exercises the
public API path and avoids duplicating download logic.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: don't depend on the GitHub API to check release
* chore: update generated content
---------
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
* fix: Use GITHUB_REF to retrieve tag before checking the most recent tag (#238)
* Update tests
* Check also tags sorted by creatordate for the current GITHUB_SHA
* fix: Check tags length
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
* Use native GitHub Action tools to download assets and use GitHub API
* Fix unexpected output when tag not found
* Use GitHub Action exec
* Add screenshot
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
