Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use pkgdown action with PR preview #865

Open
hadley opened this issue Jun 10, 2024 · 5 comments
Open

Use pkgdown action with PR preview #865

hadley opened this issue Jun 10, 2024 · 5 comments
Labels
blocked Blocked by an issue elsewhere

Comments

@hadley
Copy link
Member

hadley commented Jun 10, 2024

By copying @gadenbuie's: https://github.com/rstudio/education-workflows/blob/main/examples/pkgdown.yaml

Itt provides a nice way to preview pull requests and builds up a directory structure for tags that we can later use for versioned sites.

@gaborcsardi
Copy link
Member

I looked at that workflow, and it is a good idea, but it does not deal with concurrency at all, so I think builds will fail when other builds finished just before them.

We can use the ideas from there, but we primarily need a good way to deal with concurrency, and GHA is not helping at all.

This said, if you like that workflow, AFAICT you can use it as a drop-in replacement in your repos, just to see how it works in practice. I am going to do the same.

@gaborcsardi gaborcsardi added the blocked Blocked by an issue elsewhere label Jul 31, 2024
@gadenbuie
Copy link

but it does not deal with concurrency at all, so I think builds will fail when other builds finished just before them.

I mentioned this to Hadley that I hadn't resolved concurrency yet. IIRC pkgdown::deploy_to_branch() force pushes to the deploy branch, so the workflow doesn't fail but there could be conflicts if there are simultaneous runs. In practice, this works fine for low-traffic repos where I'm the sole maintainer.

I think concurrency can mostly be solved by pulling gh-pages and rebasing just before pushing, but that would require either changes to deploy_to_branch() or to the workflow. Pulling and rebasing will sometimes fail, in which case re-running the appropriate job should do the trick.

In general, commits from pull requests are orthogonal to other commits and a "latest wins" approach is fine. Ideally commits on main would always be run sequentially, but GHA doesn't help with that.

@gaborcsardi
Copy link
Member

For the record, we could also use netlify or cloudflare pages for OOTB live PR previews, but they both have usage limits, 300 build minutes and 300 build minutes per month, respectively.

@hadley
Copy link
Member Author

hadley commented Aug 1, 2024

The other option would be to set up something with S3, where we just eat the (presumably small) cost of hosting. But that's likely to be a non-trivial amount of work.

@gaborcsardi
Copy link
Member

Yeah, I think the simplest would be to brute-force the concurrency issue with a pull-apply-push-undo loop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Blocked by an issue elsewhere
Projects
None yet
Development

No branches or pull requests

3 participants