Persisting pdf artifacts?

[cmdcolin]

Currently there is the nice @hts-specs-bot that uploads pdf samples from PRs but the artifacts appear to 404 and then it is hard to review (trying to follow MM/MP/ML thread just for context)

e.g. https://634-3666509-gh.circle-artifacts.com/0/root/project/diff/SAMtags.pdf

Is it part of the circle ci to purge artifacts? Any way to make them more persistent?

[cmdcolin]

Managed to run the Makefile to build them locally, so technically I can read the pdf now :)

May be helpful to have a quick helper guide for how to do this for others. I used sudo apt install texlive-science (needed algorithms package) and then make on ubuntu 20

[jmarshall]

There is such a building guide, and now there is a link to it in the README on the main repository page.

Circle CI artifacts expire after a very reasonable 30 days, which is fine for PRs in progress but less good for looking back at historical ones. I think in the CI PRs we discussed having the bot use the GitHub API to edit its previous comments and/or add the PDFs to its comments as attachments rather than link directly to the CircleCI artifacts, so if someone wanted to waste even more of GitHub's disk space they could look into automating that. 😄

[cmdcolin]

Gotcha. Thanks for adding the note to the readme...maybe if they are expected to expire we can consider #556?

[jmarshall]

Since PR #641 rewrote the PDF generation infrastructure, linked artifacts no longer expire for active PRs.

Instead the PDFs are checked into the his-specs repository¹ and referenced from a preview/PR_NUM Git reference (not a branch, but fetchable by adding to your remote fetch config if you wish) so they won't be garbage-collected while the PR is active.

(When a PR is merged or otherwise closed, the corresponding preview/… ref is deleted. So the PDFs and their commits will eventually go away some time after that.)

Footnotes

1. Sadly, last time I looked, there was no API facility for working with issue/PR comment attachments. GitHub Support said this was to avoid algorithmic uploading of large amounts of data, which is fine™️ because I can't think of any other ways of uploading large amounts of data to GitHub… ↩