It would be convenient to have PDFs attached to each release.

What do you mean by "release"?

If you mean a published standard, like C++17, we are not going to provide PDFs of those. You can buy them from ISO or your national body.

Sorry, "release" was GitHub terminology. They consider every tag to be a "release"... Take a look at the "Releases" section of this repo and you'll currently see 31 as there are 31 tags.

So basically, I'm suggesting that every tag just automatically gets a PDF uploaded to go with it.

We include the released PDFs as part of the commit pointed to by the tag already. Attaching a duplicate (and hopefully identical) copy to the github releases page seems wasteful at best and error-prone at worst (if the version built by Travis somehow differs from the version that we publish -- for instance, if it's running a different version of LaTeX that produces somehow different output -- we'll have two non-identical documents carrying the same N number). Allowing Travis to build the PDF that we publish would be a significant disruption to our publication process -- we want to build and inspect the final document offline before pushing it, or the sources used to build it, to github. So I don't think that approach is going to work out very well.

How much control do we have over files showing up on the releases page? Can we nominate a suitable file from within the source archive to make it appear there?

(Separately, we should consider not tracking all the papers in the primary git repository; source checkouts of the draft are huge and growing rapidly due to this.)

Yes, if you don't want to automate it you can just attach whatever file(s) you want to the releases. You always get the zip and tarball (which contain a copy of the entire repo), but you can also upload whatever files you want.

You could also automate it to just upload "papers/${TRAVIS_TAG_NAME}.pdf" (and maybe the Markdown and HTML if you want). If that sounds appealing I can put something together for you, but the issue with the OAuth token I mentioned in the initial report would still need to be addressed.

The "normal" flow would be to just keep the LaTeX in the repo and attach the PDFs (and Markdown, HTML, etc.) to the releases, preferably automatically generated and deployed by Travis.

It would also be possible to deploy the non-tagged versions (i.e., every commit) somewhere else. Travis has a bunch of options built-in, but with a bit of effort it's generally also possible to push them out somewhere else. That would let you inspect the output of each commit before tagging a release, and if you want to make sure they're bit-exact it would be possible to automatically upload that previously-generated file to GitHub instead of regenerating it.

Finally, you can delete files from releases and upload replacements. Just click on the edit button next to the release, there is a section to add / remove files.

(Separately, we should consider not tracking all the papers in the primary git repository; source checkouts of the draft are huge and growing rapidly due to this.)

Created #3318 for this part.

Closing this ticket as no action in the desired direction will be taken.