Checksums & digests
Besides the version itself, an annotation can render a side value computed for that version, such as a checksum, a digest, or a commit. Set value to choose which.
value | Renders |
|---|---|
version | The resolved version (the default) |
commit | The commit a tag or branch resolves to (GitHub) |
sha256 | A sha256: digest or asset checksum |
# clover: provider=github repository=cli/cli id=gh constraint=minor
version: 2.40.0
# clover: from=gh value=sha256 pattern=*_linux_amd64.tar.gz
checksum: 17f3c21f3f4c3b0175a9a0ee8f8e42e36f58e2713de81440ea9c0cb94c5a08a8
A side value is only refreshed when its version actually changed, so a checksum never drifts out of step with the version it belongs to. This is also a safety guarantee: a digest that was once pinned never moves on its own, so a re-published artifact cannot silently change a checksum under an unchanged version. Pass --force (or set run.force in .clover.yaml) to deliberately re-pin every followed digest against its current version, for the rare case where an upstream release was legitimately re-published.
Sourcing a sha256
sha256-source controls how the checksum is obtained:
| Source | Behavior |
|---|---|
auto | Digest, then a checksums file, then download (the default) |
digest | Use the provider’s asset digest, no download |
checksums | Read a published checksums file (sha256-url, or a sibling asset) |
download | Download the asset and hash it |
verify | Require the digest and the checksums file to agree |
Two keys refine checksums/download:
sha256-urlis the checksum-file URL, templated with<version>.patternis an asset filename glob selecting which asset to hash.
On a private GitHub repository, assets and sibling checksum files are read through the authenticated API rather than the public download URL, so checksums and download work wherever discovery does.