-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 the GH webhook payload to parse PR details #4817
Conversation
…ITHUB_REF if the build type is pull_request.
So the behavior from the GitHub Actions sounds like it makes sense to me, or at least seems reasonable.
The So that's probably why you couldn't associate the SHA with anything, because it's not the SHA of the pull request branch, but the "pull request branch + target branch". The [GitHub event(https://github.com/pulumi/docs/pull/3584/checks?check_run_id=766615693#step:13:7) printed a "synchronize" action, which if I recall correctly is what happens whenever a push is made to a branch that is tracked by a pull request. The Pulumi GitHub app listens for those and writes them into the
That sounds right. And appears to be what the Pulumi GitHub App is doing when it sees the "synchronize" event as well. (Code). |
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 for tracking this down Praneet! Definitely a pain, double-checking the output you saw from the GitHub Actions at runtime, this does look like the right way to gather this information.
The only suggestion is that maybe we would want to confirm the githubActionsPullRequestEvent
action
field? Since there are a bunch of different ones, and potentially the way we would interpret the SHA/branch might be different? (But it doesn't look like the case, since I doubt the workflow would trigger in response to the GitHub PR having review_requested
or being locked
, etc.)
!
Correct. The values of the env var as-is makes sense to me as well. I am just not sure when
Correct. I pasted the link to the GHA execution for the
Yeah it doesn't seem to be the case. The CLI would just need to take whatever value is in the PR webhook payload from the workflow environment. I do have a check that we would parse the webhook payload event only if |
Related to #4758 and #4613.
In a previous PR, I added the CI env vars detection for GH Actions. Unfortunately, it looks like there is some problem with the values of
GITHUB_REF
andGITHUB_SHA
for a PR. It looks like the example shown in the doc is not what we are actually seeing. To demonstrate this, I opened a draft PR in our docs repo, which has an extra step to print out the env vars and the event JSON separately. Note how the value of theGITHUB_REF
value does not match the documented example ofref/heads/<branch name>
. And forGITHUB_SHA
-- I actually can't even tell what this SHA is. It doesn't look like it is the value of anything that I can correlate. Perhaps I read the docs incorrectly and misunderstood what they were supposed to be.In any case, if you look at the event JSON, the values that we are looking to use are correctly specified in there, including the
pull_request.head.ref
, which has the PR branch name and the SHA value inpull_request.head.sha
.In addition to the problem with the values of the two env vars, the PR number extraction was incorrect. In the previous PR, I was trying to unmarshal the value of the
GITHUB_EVENT_PATH
directly, which will never work since it is just the path to the JSON file that actually contains the event. This would have only caused us to not set theci.pr.number
env metadata key. I have fixed this as well now.