Upload generated PDFs to GitHub releases from Travis

[nemequ]

It would be convenient to have PDFs attached to each release. With a bit of configuration, this can be done automatically from Travis; I made the necessary changes at nemequ/cppdraft, but I can't just file a PR since it will have to be tweaked to set a correct API key (and repo name) for this repo.

I went ahead and added a n0000 tag so you can see the effect.

Travis has some documentation explaining how to deploy to GH releases using an OAuth key. Notice that last paragraph; they suggest creating a dedicated user since the keys are for your user, not a specific repository... seems like a good idea to me.

If you want I can create an account and put everything together, then just turn over the credentials to you. If I do that I could just file a PR. Otherwise...

Once you've created a user, you can use the travis CLI to get the OAuth token, encrypt it, and add it to the .travis.yml with travis setup releases. It mangles the .travis.yml file pretty badly, it's still the easiest way to get the encrypted token.

After you have the token,you just need some small tweaks After that you'll just want to add a couple conditions to the deploy hook, and tweak the build a bit to copy the generated PDF out of the Docker container, etc. Basically, just grab the .travis.yml from my repo, replace repo: nemequ/cppdraft with repo: cplusplus/draft and replace the API key.

[jwakely]

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.

[nemequ]

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.

[zygoloid]

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.)

[nemequ]

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.

[jensmaurer]

(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.

[jensmaurer]

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