-
-
Notifications
You must be signed in to change notification settings - Fork 123
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
Why is GITHUB_TOKEN
necessary?
#218
Comments
I see the code and comment below, which indicates that action-semantic-pull-request/src/index.js Lines 38 to 46 in 0b14f54
This leads me to believe that the authenticated https://docs.github.com/en/actions/using-jobs/using-concurrency |
I traced that comment back to the PR below. It doesn't seem that there's any additional context in the PR description. |
Hey @ajschmidt8 and thank you for your comment! The reason why I added the necessity for the token is described in the comment from the code snippet you've linked to above. If you know how to avoid this while still being able to support the same feature set, I'd be more than happy to review a PR! |
@ajschmidt8 Can you say more about why this is a race condition? Let's discuss what the concurrency fix is. |
If a PR title is updated multiple times in quick succession, then it could trigger the workflow to run multiple times in parallel. This could cause problems depending on the details of the title changes on each trigger. To prevent this workflow from running multiple times in parallel, you could set up concurrency limits like this: name: "Lint PR"
on:
pull_request_target:
types:
- opened
- edited
- synchronize
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
main:
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v5 This would ensure that any pending workflow runs are canceled before a new one begins. I don't think that's related to the Upon further inspection of the source code, it's the following code block that requires users to use the action-semantic-pull-request/src/index.js Lines 149 to 162 in ff373f4
This command writes a custom status back to the PR depending on the results of the function. The default Composite actions aren't typically supposed to write additional statuses to PRs. They're simply supposed to run some code and exit with a non-zero code if there are problems. Writing additional statuses is what requires a |
I think that's true. Also, the workaround of calling the Github API wouldn't fix it systematically, just reduce the frequency by adding a little latency. Also, I think you're right that this isn't why the pull_request_target trigger is necessary. I'm not sure that pull_request_target changes the privilege level of the token, though. The architecture documented in the securitylab.github.com blog might be the fix:
|
Agreed, the API hits to read pull request data shouldn't be necessary. Those details are included in the payload provided by GitHub.
Check the details here: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target Specifically the red warning (emphasis mine):
|
I'm wondering why a
GITHUB_TOKEN
is necessary for this action to work correctly.Both
pull_request
andpull_request_target
events deliver a payload that contains the current pull request title (src). The full payload is available via thegithub
context under theevent
property (src).The text was updated successfully, but these errors were encountered: