build(tools): serve the FastQC archive from this repository's releases - #54
Conversation
On 2026-09-22 CI went red on a commit that touched nothing near FastQC: www.bioinformatics.babraham.ac.uk served an expired TLS certificate. The gate fix in #51 made that legible and retryable, but it could not remove the dependency, because FastQC publishes no GitHub release assets -- all six of its GitHub releases carry none -- so the pinned URL could only ever point at that one host. A third party's certificate renewal could stop our builds, and did. So the archive is vendored: same bytes, served from this repository's own releases (tagged vendored/fastqc-v0.12.1, marked pre-release because it is a build input rather than a version of this software). CI now installs it over a connection to GitHub, the same host that already serves vsearch and swarm, and the FastQC host leaves the critical path for building and reproducing the pipeline. The provenance is stated rather than glossed. The capture used `curl --insecure`, because upstream's certificate was already invalid when the file was taken. Integrity does not rest on that transfer: the sha256 in the pin is UNCHANGED from the original upstream pin, established while upstream was healthy, and the captured file verifies against it. Nothing changed except who serves the file -- and that is checkable, because the vendored download was verified byte-for-byte against a fresh upstream copy. Guarded, because the failure mode is silent: a URL that quietly points back at a third party still downloads and still verifies. The new testset fails by name if the pin returns to its old host or stops being a release of this repository (mutation-tested: repointing it at babraham.ac.uk fails two assertions by name). The vendored checksum is asserted too, so a future bump has to be a decision rather than a drift. docs/compliance/vendored-archives.md records the rule -- the checksum is the integrity claim and never the transport, never re-checksum to make a download succeed, the licence travels with the archive, and repointing back at a third party is a decision -- with the entry for this archive and the procedure for adding the next one. Refs #30, #51
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🧰 Additional context used🪛 LanguageTooldocs/compliance/vendored-archives.md[locale-violation] ~33-~33: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”. (LICENCE_LICENSE_NOUN_SINGULAR) [formatting] ~39-~39: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause. (COMMA_BEFORE_BECAUSE) [formatting] ~44-~44: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause. (COMMA_BEFORE_BECAUSE) 🔇 Additional comments (3)
📝 SummarySummary by CodeRabbit
WalkthroughThe FastQC 0.12.1 archive now uses a vendored GitHub release URL. The original version and SHA-256 remain unchanged. New documentation records the vendoring policy and archive details. A unit test checks the URL host and checksum. ChangesFastQC vendoring
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to FastQC now downloads from the repository’s vendored release while preserving checksum verification. No concrete merge-blocking risk remains, so this change is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit checks the archive trail Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
1 participant
Refs #30, #51 — removes the dependency the gate fix could only make legible.
The problem, precisely
On 2026-09-22 CI went red on a commit that touched nothing near FastQC:
www.bioinformatics.babraham.ac.ukserved an expired TLS certificate. #51 made thatretryable and self-describing, but it could not remove the dependency, because FastQC
publishes no GitHub release assets — all six of its releases carry none — so the
pinned URL could only ever point at that single host. A third party's certificate renewal
was able to stop our builds, and did.
The fix
The archive is vendored: same bytes, served from this repository's own releases —
tagged
vendored/fastqc-v0.12.1, marked pre-release because it is a build inputrather than a version of this software.
config/defaults/tool_versions.ymlnow points athttps://github.com/hyperpolymath/MetaManifold-WebUI/releases/download/vendored/fastqc-v0.12.1/fastqc_v0.12.1.zipwith the checksum unchanged. CI installs FastQC over a connection to GitHub — the
same host that already serves vsearch and swarm — so the FastQC host leaves the critical
path for building and reproducing the pipeline.
Provenance, stated rather than glossed
The capture used
curl --insecure, because upstream's certificate was already invalidwhen the file was taken. That is worth saying out loud, because it is the one detail a
reader should not have to infer.
Integrity does not rest on that transfer: the sha256 in the pin is unchanged from the
original upstream pin, which was established while upstream was healthy, and the
captured file verifies against it. I also downloaded the published asset back over an
anonymous connection and confirmed it is byte-for-byte identical (
cmp) to a freshupstream copy. Nothing changed except who serves the file.
Licence: the archive carries its own
FastQC/LICENSE.txt(GPL v3) and is redistributedunmodified.
Guarded, because the failure mode is silent
A URL that quietly points back at a third party still downloads and still verifies. The
new testset fails by name if the pin returns to its old host or stops being a release
of this repository, and asserts the vendored checksum so a future bump is a decision
rather than a drift. Mutation-tested: repointing the pin at
babraham.ac.ukfails twoassertions by name; with the pin correct the file passes 126/126.
docs/compliance/vendored-archives.mdrecords the rule — the checksum is the integrityclaim and never the transport; never re-checksum to make a download succeed; the licence
travels with the archive; repointing back at a third party is a decision — with this
archive's entry (upstream URL, sha256, licence, capture date, why) and the procedure for
adding the next one.
check-format,check-spdxandlint_source.jlare clean.