7f4bb4cccf
Wire up scaleway/scaleway-cli as a watched package (extra's copy lags
weeks behind upstream). Getting a real second package running exposed
gaps uv's config never hit:
- asset_pattern/checksum_asset_pattern now support a {version}
placeholder for release assets that embed the version in the
filename (checker::version_from_tag strips a tag's leading `v`).
- same-origin-sha256 now matches the checksum line by filename instead
of assuming a single-hash file, to support combined multi-asset
checksum files like scaleway-cli's SHA256SUMS.
- latest_github_release now confirms each Atom-feed candidate against
the releases API instead of trusting the newest entry outright —
scaleway-cli publishes a `-dbg1` tag with no real Release object that
otherwise sorts newest in the feed.
Confirmed correct against the real repo: no attestations upstream, so
tier 4 (same-origin-sha256) applies, and the checker correctly skips
the dbg1 tag to land on the real latest release.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
17 lines
736 B
TOML
17 lines
736 B
TOML
# Verified 2026-09-17 against the real repo: scaleway/scaleway-cli does not
|
|
# publish GitHub build-provenance attestations (the attestations API 404s
|
|
# for a fresh release asset) — tier 4, same-origin checksum only, not tier
|
|
# 2. Motivation: Manjaro's `extra` scaleway-cli lags upstream by weeks;
|
|
# this tracks upstream releases directly instead.
|
|
#
|
|
# Releases ship one combined `SHA256SUMS` file (one line per platform
|
|
# asset) rather than a per-asset checksum file like uv's — verifier
|
|
# matches the line by filename.
|
|
|
|
[package.scaleway-cli]
|
|
repo = "scaleway/scaleway-cli"
|
|
asset_pattern = "scaleway-cli_{version}_linux_amd64"
|
|
|
|
[package.scaleway-cli.verification]
|
|
method = "same-origin-sha256"
|
|
checksum_asset_pattern = "SHA256SUMS"
|