Use GitHub's release asset digest field in the github-release-attachments datasource

[cfraenkel]

Tell us more.

Disclosure: I used AI assistance to research the source and draft this post. The measurements and source references were verified by hand.

Summary

github-release-attachments identifies release assets by downloading and hashing them.
GitHub has exposed a SHA256 digest on every release asset since June 2025, but Renovate does not read it.
For projects whose checksum manifest Renovate cannot use, a digest lookup downloads and hashes assets in ascending size order until the artefact is reached: up to 542MiB for lego and 1220MiB for seaweedfs, repeated whenever the 24h cache expires.

Why I am opening a new discussion

This was already requested in #37152, "Retrieve GitHub release asset digests from GitHub API".
That discussion was closed as resolved and locked on 2025-10-14, citing #37151.

I believe the close was premature.
#37151 is titled "support releases removed checksum files" and added the download-and-hash fallback, which #37152 mentioned only as the mechanism to keep as a fallback.
The API-digest read that #37152 actually asked for does not appear to have landed.

As of e8568a2 on main (2026-08-11), GithubRestAsset in lib/util/github/types.ts declares:

renovate/lib/util/github/types.ts

Lines 17 to 22 in e8568a2

	export interface GithubRestAsset {
	name: string;
	url: string;
	browser_download_url: string;
	size: number;
	}

There is no digest field, and a search for asset.digest across the repository returns no usage.
Since #37152 is locked I cannot follow up there, hence this new post.
Happy to have this merged back into #37152 if a maintainer prefers.

Current behaviour

findDigestAsset() in lib/modules/datasource/github-release-attachments/index.ts uses two strategies:

1. findDigestFile() downloads every asset smaller than 5 KiB, treats each as a checksum manifest, and looks for a line whose digest equals the current one.
2. findAssetWithDigest() sorts all assets ascending by size, then downloads and hashes each one until a digest matches.

Both are content-based searches.
Neither uses the asset metadata GitHub already returns in the same releases/tags/{tag} response that the datasource is already fetching.

Impact

Measured with gh api repos/{repo}/releases/tags/{tag}, for three projects I pin by digest:

Repo	Tag	Assets	Total size	Assets exposing digest	Assets under the 5 KiB scan threshold
seaweedfs/seaweedfs	4.41	72	1220 MiB	72 / 72	36, all 33-byte .md5 sidecars
go-acme/lego	v5.3.1	59	542 MiB	59 / 59	0
smallstep/cli	v0.30.6	132	856 MiB	132 / 132	0

Every asset already carries the digest Renovate is trying to compute, and all three still take the download path.

For lego and smallstep/cli this is worth spelling out, because both do publish a SHA256 manifest:

• lego_5.3.1_checksums.txt is 6114 bytes
• checksums.txt is 6022 bytes

Both are just over the a.size < 5 * 1024 filter in findDigestFile(), so neither is ever parsed.
Neither release has a single asset below 5120 bytes, so strategy 1 opens nothing at all and strategy 2 runs the full walk.

The manifest does still get downloaded, just not used: being the smallest asset, it is the first thing findAssetWithDigest() fetches and hashes as an opaque blob.
I confirmed this against a release shaped like lego, with a valid 6114-byte manifest naming the artefact.

seaweedfs fails strategy 1 for a different reason: it publishes no SHA256 manifest, and its 36 sidecars are under the threshold but contain MD5, which can never match a SHA256 currentDigest.

So a single digest lookup walks the release by ascending size until it reaches the artefact, and with cacheHardTtlMinutes at the default this repeats on cache expiry.

This is not just an inference from reading the code - my local test branch has coverage for this.

Proposal

Match on the digest the API already returns before falling back to the two existing content-based strategies, which stay as-is for releases published before June 2025.

For most repositories this turns a multi-hundred-MiB download into a field read on a response the datasource has already fetched.
This is what #37152 proposed.

Possible side benefit

This may also address #36182, open and unanswered since 2025-05-27, where a checksum sidecar containing a bare hash with no filename leaves digestedFileName undefined, and Renovate writes back the digest of the checksum file rather than of the artefact.
An asset-metadata match never consults a sidecar, so releases carrying a digest never reach that code path.
The reproduction in that discussion uses EmbarkStudios/cargo-deny, whose current release 0.20.2 exposes a digest on all 10 assets, so it would take the new path.

I have not run the reproduction itself, and this would not help releases published before June 2025, which have no digest and still depend on the sidecar parsing.

Offer

I am willing to open a pull request for this.
I have a working local prototype against e8568a2: purely additive, 241 insertions and 0 deletions across 4 files, with both existing strategies untouched as fallbacks.
The datasource's tests pass (23 tests) with 100% statement, branch and function coverage on the changed files.
I will leave the implementation detail out of this post and put it in the PR, unless you would rather discuss the approach here first.

Before opening the PR I would like a maintainer to confirm the feature is genuinely still missing and that this approach is wanted, since #37152 was marked resolved.

[RahulGautamSingh]

PR welcome, thanks!

[cfraenkel]

Sure, I'll create one soon.

[cfraenkel]

could you create an Issue I can reference please?

[RahulGautamSingh]

#45343