Run on pull requests #73
Conversation
The gh pr list command now fetches the pull request number and constructs the correct reference format (refs/pull/{pull_number}/merge) for each pull request branch.
This reverts commit 94d22e8.
This reverts commit 2b76ef1.
This reverts commit 4fe2eda.
This reverts commit eb01e60.
This reverts commit 9c6192c.
|
It more or less works: a workflow is triggered for pull requests and it builds the book successfully. However, when the commit is done on the forked repo, it seems the workflow doesn't have the authorization to update the github pages website on the original repository, see https://github.com/Tom-van-Woudenberg/jason_test/actions/runs/12925653497/job/36047161353#step:14:32 |
|
Most people use something like netlify to host temporary viewable HTML outputs from CI builds. I am not sure if a PR author can have the permissions to update the primary repo's github pages. That just may not be possible, that would mean that anyone could spam your websites with their PRs. |
We use GitHub pages for all html outputs, temporary or permanent :)
Yeah makes sense, although it would be desired in our case. I'll add something to the action summary indicating that a run from the original repo is required too. |
1 similar comment
We use GitHub pages for all html outputs, temporary or permanent :)
Yeah makes sense, although it would be desired in our case. I'll add something to the action summary indicating that a run from the original repo is required too. |
I don't think the PR builds -> pages are possible then. |
Okay, I'll rethink about whether this PR build functionality has any value without the possibility of the 'fork' people to initiate it... The workflow can run in the fork itself too if a preview is needed |
|
There is value, which is seeing if the build completes and if not you get all the error messages. That's all I was after when I suggested it. Trying to deploy to temp websites, is an extra feature I suppose. You could just disable the step that tries to push the website content to a new page and then anyone who makes a PR still gets lots of useful info. |
|
@moorepants, I think that's what I've implemented now. Summaries include errors (during build, not before): Fancy reviewing this? |
@moorepants , can I count your thumbs-up as a positive review? |
|
I have no dissent for you running these on pull requests in addition to commits on master. It was just a suggestion to help users make pull requests and get CI feedback without being a repo owner/collaborator. I did just learn that read the docs has a new feature to display preview builds from PRs. Maybe that could be used for you. It is quite simple to set up. See the CI runs here:
|
Interesting! I've my doubts about read-the-docs for the final 'published' versions of our books (which are now on github pages) because of the advertisement and the addition of another platform. However, it could be interesting for PRs indeed! I'll discuss with @douden , @FreekPols and @rlanzafame later today |
|
Yeh, you may not want to have the final product on RTD but it was, by far, the easiest solution to have a preview build from a PR that I have come across. I'm going to switch all my repos to it. |
|
As discussed, implemented read-the-docs because of github pages doesn't allow push to github pages on fork update: TeachBooks/manual#102 |
No description provided.