-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comment PRs with updated schedule information #1576
Conversation
Course ScheduleWith this pull request applied, the course schedule is as follows: Fundamentals21 hours and 45 minutes: (2 hours and 15 minutes short)
|
f2b2310
to
840bcf5
Compare
@@ -0,0 +1,25 @@ | |||
name: "Course Schedule Updates" | |||
on: | |||
- pull_request_target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the schedule in this PR won't update, since this directive indicates that the action should run based on configuration in the target branch -- and it hasn't been merged yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably think about the implications of this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use
on:
pull_request:
in the build.yml
. The difference is that pull_request
run the action in the context of the (future) merge commit, whereas pull_request_target
runs at the base of the branch.
Are you running it at the base to enable the read/write behavior of the GITHUB_TOKEN
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. But, I didn't realize that the checkout will check out the base as well. That means we don't get the info on the timings in src/
without more effort.
We could do a git checkout $rev src/
of the PR revision, but that relies on mdbook parsing as a security boundary, which is probably not adequate.
Maybe there's a way to split this into two actions -- one that runs on pull_request and does the analysis, and one that runs on pull_request_target and just posts the resulting analysis to a comment. I'll look into that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's necessary to split it. Pull requests from new contributors have to be approved before they run — precisely to protect against injection of malicious build steps.
So it should be fine to add the necessary permissions:
key to a regular build: we check that the job doesn't change in strange ways before we approve PR builds for new contributors.
That's the theory, as far as I understand it 😄 The real problem is if this understanding is wrong and/or if it's not shared with others who have write access to the repository.
Hm, it appears that jobs from pull_request and pull_request_target cannot have inter-dependencies because they are in different workflows. So I can't upload an artifact in a I think reusing workflows is more of a subroutine call, and can't cross security boundaries, which is why we need two workflows here. Artifacts are handled as ZIP files (e.g., https://github.com/google/comprehensive-rust/actions/runs/7215251310) so we can't just link to an artifact and hope it springs into existence before someone clicks the link. Are there any GitHub actions gurus who might be able to give me a hint here? |
f4d8cd5
to
07af655
Compare
Per discussion with @mgeisler I've updated this to just do the simple thing, and rely on reviewers verifying PRs and clicking the run-actions button to check for malicious behavior. |
@mgeisler do could you have another look here? |
dc86815
to
1b1633c
Compare
Yes, let me get this reviewed! |
permissions: | ||
pull-requests: write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From Permissions for the GITHUB_TOKEN, I think this will be ineffective for PRs that come from forks.
I guess we'll figure it out soon after merging it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I misunderstood earlier suggestions - does this not run when we click "Run Actions" for an untrusted fork?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does run, but it fails because the token is downgraded. That's how I interpret the error I just saw in #1693:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me think that we should remove this again, sorry!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'm looking forward to seeing this in action.
Co-authored-by: Martin Geisler <[email protected]>
Hm, do I need to hand-apply the diff from that "Test / format" failure? |
It should, |
Will be fixed with #1694. |
The GitHub action fails because it cannot run with the necessary permissions: it requires write access to be able to post a comment, but when triggered from a fork, the token is limited to read access. The error is from the thollander/actions-comment-pull-request action: No comment has been found with asked pattern. Creating a new comment. Error: Resource not accessible by integration The downgrading of the token is explained on: https://docs.github.com/en/actions/security-guides/automatic-token-authentication where “Maximum access for pull requests from public forked repositories” says that the pull-requests permission is capped at read in the typical case for us. I kept the underlying functionality since we might want to use it for something else (perhaps track the duration in the README). Fixes the errors seen on the recent PRs: #1693, #1687, and likely others.
The GitHub action fails because it cannot run with the necessary permissions: it requires write access to be able to post a comment, but when triggered from a fork, the token is limited to read access. The error is from the thollander/actions-comment-pull-request action: No comment has been found with asked pattern. Creating a new comment. Error: Resource not accessible by integration The downgrading of the token is explained on: https://docs.github.com/en/actions/security-guides/automatic-token-authentication where “Maximum access for pull requests from public forked repositories” says that the pull-requests permission is capped at read in the typical case for us. I kept the underlying functionality since we might want to use it for something else (perhaps track the duration in the README). Fixes the errors seen on the recent PRs: #1693, #1687, and likely others.
The GitHub action added in #1576 fails because it cannot run with the necessary permissions: it requires write access to be able to post a comment, but when triggered from a fork, the token is limited to read access. The error is from the thollander/actions-comment-pull-request action: No comment has been found with asked pattern. Creating a new comment. Error: Resource not accessible by integration The downgrading of the token is explained on: https://docs.github.com/en/actions/security-guides/automatic-token-authentication where “Maximum access for pull requests from public forked repositories” says that the pull-requests permission is capped at read in the typical case for us. I kept the underlying functionality since we might want to use it for something else (perhaps track the duration in the README). Fixes the errors seen on the recent PRs: #1693, #1687, and likely others.
So it seems this was not a working solution :( |
Yeah, sorry about backing it out in #1700. The permission system here is rather confusing. I get the impression that a GitHub app is the way to go — but that's probably complex to set up. |
This reverts commit 60c5a33.
This adds a GH action to add a comment to every PR giving the updated course schedule with the PR merged.
To accomplish this, I broke
mdbook-course
into a library and two binaries, allowing the mdbook content to be loaded dynamically outside of anmdbook build
invocation.I think this is a net benefit, but possible improvements include:
<details>
(with a few minutes effort I couldn't get this to play nicely with the markdown lists)