Make catalog validation real and guard against link rot#4
Merged
Conversation
Harden the CI that keeps this catalog installable. The previous PR check silently verified nothing: it derived its file list from `git diff origin/main...HEAD` against a shallow checkout with no origin/main ref, so the list was always empty and schema/URL/checksum validation never ran. It reported success in seconds having checked no manifests. This replaces it with validation that always runs against the whole catalog: - Schema-validate every plugin manifest, resolve every advertised download URL, and verify each archive's sha256 against the manifest — so a wrong checksum or a missing release asset fails in CI, not in a user's install. - Gate index.yaml on being in sync with plugins/. It is what datumctl reads and is fully derived from the manifests, so CI regenerates it and fails on drift. This keeps main's index correct by construction and removes the bot-authored "regenerate index" pull request that previously trailed every merge. - Add a weekly health check that re-verifies the entire catalog and opens an issue when a plugin's links or checksums have rotted, since those assets live in other repositories and can change after a plugin lands here. The generator and verifier are committed as scripts so contributors and CI run exactly the same logic; the README documents regenerating the index.
ecv
approved these changes
Jul 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The catalog's job is to make plugins installable and trustworthy. Its CI wasn't doing that.
The PR validation check was a false green: it built its file list from
git diff origin/main...HEADagainst a shallow checkout that has noorigin/mainref, so the list was always empty. Schema, URL-resolution, and checksum verification never ran — the check passed in ~6s having validated nothing. (Seen directly on #1, where the job's log showsfor f in ; do.)What this changes
datumctl plugin install.index.yamlcan't drift. It's the filedatumctlreads and is fully derived fromplugins/*.yaml, so CI regenerates it and fails the PR if the committed copy doesn't match. This keepsmaincorrect by construction — and removes the bot-authored "regenerate index" PR that used to trail every merge (the exact drift that caused the merge conflict on Register the IPAM CLI plugin #1).The generator and verifier are committed as
scripts/so contributors and CI run the identical logic; the README documents regenerating the index before opening a PR.Verification
Ran both scripts against the live assets: all 12 archives across
ipamandinventoryresolve and match their checksums, and the index is in sync. Negative tests confirm a mutated checksum and a drifted index each fail with a clear message.actionlintis clean.Related