manubot
Deploy pull request manuscripts to webpage when possible
@leehart had a cool idea at https://github.com/manubot/rootstock/issues/198#issuecomment-648317044 to deploy rendered manuscripts from pull requests. This won't work for all pull requests due to permissions issues (specifically pull requests coming from a fork).
However, it could be really helpful for PRs originating from branches in the same repository. Proof of concept implemented by @leehart in https://github.com/malariagen/ag1000g-phase3-data-paper/pull/9.
I'm looking forward to following how this solution works for the ag1000g-phase3-data-paper. Possibly this is something we want as an option for all manuscripts.
One way to implement this would be to add the functionality to the manubot webpage command (source code).
Deploying a PR commit is pretty similar to deploying a regular commit, except that:
- do not update
v/latest - do not update
v/freeze - do not update manuscript in webpage root
- create
v/pr/[pull_request.number]that symlinks tov/[commit]. Or just store the rendered manuscript in thev/prdirectory.
Some things to consider is whether this will cause repos to bloat. And if so, will there be an easy way to delete versions for closed PRs?
Also we could make the feature opt-in until we're more certain of its longterm impact.
will there be an easy way to delete versions for closed PRs?
I could imagine having a scheduled workflow that does a nightly cleanup of the pull request builds in the gh-pages branch. It could get the PR number for all closed pull requests, cross-reference that with the v/pr/[pull_request.number] numbers, and delete directories as needed.
Does the pull request build for a branch on a forked repo have permission to write back to the gh-pages branch of that forked repo? I'm mostly just curious. It could get confusing to actually deploy the rendered manuscripts in the forked report.
For what it's worth, with regards to bloat, it actually works out OK for us when any update to the master branch (via PR merge, etc.) also recreates the gh-pages, branch by design, wiping out all PR deployments, which had become out-of-date anyway. This forces us to update our PRs with the latest from master, in order to get another PR deployment. But I can imagine that would be unexpected or inconvenient for some.
