ci: fetch the qpx example from a working URL - #708
Conversation
Add QPX support and enhance PMultiQC documentation
Minor updates and merge from dev branch
The PRIDE copy of qpx_example.zip returns 404, so the test_qpx job fails at the download step. This is specific to that one file, not a PRIDE outage -- the other assets this workflow pulls from the same host still serve fine (LFQ_PXD007683.zip returns 200, 408 MB), so the remaining 24 PRIDE URLs are left alone. Points at the GitHub attachment copy instead. Verified it is the same file: identical size (831,756 bytes) and identical sha256 (02c2a9bd314d81ebc50d0b24c98fe9aec526c8ce8d032fc9f38fe3251f435154), same 16 entries including results/multiqc_config.yml which the job passes to --config. Ran the job's three steps locally against main with a clean Python 3.12 install: download, unzip, and the multiqc invocation. Exit 0, no tracebacks, no swallowed failures, 24 sections, no duplicate anchors, 2.6 MB report. Adds -O so the output name does not depend on the URL's trailing path.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Same 404 as the CI job: docs/config.json drives the example-report generation and both qpx entries (qpx and qpx_disable_hoverinfo) pointed at the PRIDE copy of qpx_example.zip, which no longer exists. The README download link pointed there too. All three now use the GitHub attachment, verified identical by sha256 (02c2a9bd...f435154, 831,756 bytes). Only the qpx URLs change. The other 44 PRIDE URLs in config.json are fine -- PRIDE itself is up, it is this one file that is missing. Also makes the FTP attempt conditional in update_examples.py. download_file rewrites https:// to ftp:// and tries FTP three times with backoff before falling back to HTTPS; against a host that never served FTP that is three connection timeouts plus ~6s of sleep, twice, for no possible gain. It now tries FTP only for hosts named ftp.*, so PRIDE keeps its retries and HTTPS-only hosts go straight to the path that works. Verified with the real downloader against the updated config: HTTPS on the first attempt, 831,756 bytes, 0.7s.
1 participant
The
test_qpxjob fails at its download step: the PRIDE copy ofqpx_example.zipreturns 404.This is not a PRIDE outage. Other assets this workflow pulls from the same host still serve fine —
LFQ_PXD007683.zipreturns 200 (408 MB) — so it is specific to that one file. The other 24 PRIDE URLs in the workflow are left untouched.The replacement is the same file
Verified rather than assumed:
02c2a9bd314d81ebc50d0b24c98fe9aec526c8ce8d032fc9f38fe3251f435154The sha256 matches the copy previously downloaded from PRIDE byte for byte, and the archive has the same 16 entries — including
results/multiqc_config.yml, which the job passes to--config.Verified by running the job
All three steps executed locally against
main, with a clean Python 3.12pip install .to match CI:Result: exit 0, no tracebacks, no swallowed failures, 24 sections, no duplicate anchors, 2.6 MB report.
Also adds
-O qpx_example.zipso the local filename does not depend on the URL's trailing path.Worth considering separately
A GitHub user-attachment URL is a reasonable unblock, but it is tied to a comment upload rather than a managed release asset. If this dataset is meant to be a long-lived CI fixture, restoring it on PRIDE or attaching it to a tagged release would be more durable.