Have SYW github action post built pdf in pull requests

[adrn]

It would be useful to be able to have quick access to the rendered PDF generated during a pull request build of a manuscript.

[rodluger]

The current behavior for PRs is for a build artifact to be generated containing the PDF and some other goodies (instead of force-pushing to the -pdf branch). Does that work for you?

[adrn]

That is a solution, but it would be cool if there was a nicer way of exposing a direct link to the pdf, like how clicking the "details" button on a readthedocs CI run on a PR takes you directly to a rendered version of the html docs. It would be nice if there was a way of exposing a direct link to the pdf so that it renders in browser without having to download, unzip, view locally.

[adrn]

(btw, to be clear, I've looked into this in the past for other contexts and there wasn't an easy solution, but maybe there is now?)

[dfm]

It might be possible to add it as an attachment to a comment using the GitHub API? I don't know, but that could be cool if possible!

[rodluger]

Unfortunately @dfm's suggestion doesn't seem possible at the moment: https://stackoverflow.com/questions/63547702/add-attachment-to-github-issue-from-the-command-line https://github.com/isaacs/github/issues/1133

[dfm]

Alas 😢

[rodluger]

Any other ideas? If the PR is coming from a fork, we could just link to the file on the *-pdf branch on that fork...

[adrn]

I have one other idea but haven't successfully implemented it, so it might not work! It's a bit of a hack, but I started sketching it out here: https://github.com/adrn/store-artifact-on-branch/

[rodluger]

@adrn any more thoughts on this? Let's chat on Monday if you have time?

[adrn]

I'll be in tomorrow, so chat then?

[rodluger]

This is now working, but not yet documented. There's no way to grant the GitHub Actions runner write access to either the base repo or the head repo in a pull_request run; we have to use the pull_request_target trigger. This one comes with a whole host of security hazards, so I set up functionality to only run the build if the PR is first labeled safe to test by a maintainer. This must be done every time the pull request is updated (synchronized) to prevent bait-and-switch exploits. The exception is a PR originating from the same repository, which is always deemed safe to build.

When the PR is built, the pdf is pushed to a branch called pull-request-<PR_NUMBER>-pdf.

By default, pull_request_target is commented out in the build.yml workflow for extra security. @adrn and @dfm, give this a spin when you get a chance (no rush)?

[rodluger]

Actually, I take it back. That was a fun exercise but I think a far better solution is using the workflow_run trigger explained here. The idea is to run the PR under a regular, unprivileged pull_request trigger, have it upload an artifact, then unzip the artifact in privileged (but not exploitable) workflow_run trigger and force-push the compiled PDF to a new branch. Going to implement this soon.

[rodluger]

This is working now!