GitHub Community
Feature Request: Helpful details for building bots for PR-related actions #26109
-
|
I’ve been porting some CI tooling to GitHub Actions; the experience has been pretty good overall, but I’ve hit three rough edges that would be nice to be smoothed out. The first two have workarounds, but they aren’t great; a baked-in solution would be much nicer. 1. An Action that triggers on a Pull Request can’t easily get the PR number. If you have an action triggering on a Pull Request, you may need to hit the Github API to get details about the PR. To do this, you need to know the PR number; however, that value isn’t present in the environment. You *can* extract this value by parsing 2. An Action that triggers on a Pull Request can’t easily get the hash that triggered the Action When a PR triggers an action, the repository that you receive as a checkout *isn’t* at the SHA hash of the commit that stimulated the PR - it’s the SHA of the *merge commit* that would be generated if the PR was accepted. This is the SHA that is reported as ${{ github.sha }} However, that SHA *isn’t* part of the repository until the PR is merged; so if you want to do something like post a comment on the PR, you have to reverse engineer a hash that *is* currently part of the repository. As a workaround, you can extract the SHA of the parent of the merge commit (e.g, with 3. All comments posted by an Action are posted as the github-actions user If you’re on an Open Source project, almost none of your contributions are internal; they’re all from forks. Some Open Source projects also make extensive use of bots to automate common actions (such as providing automated code review comments). However, Actions don’t allow secrets to be exposed to pull requests originated from forks. You can use the GITHUB_TOKEN - but all actions performed using that token are performed by the “github-actions” user. If you have multiple bot actions that you need to be performend, it can be helpful for those bots to have different identities (e.g., one bot that welcomes new contributors, a second providing code review, etc); however, being forced into a single auth token mean you lose any ability to expose unique identities. I don’t have a workaround for this last one, other than just accepting that all actions will be performed by the github-actions user. Having the ability to nominate the user/bot whose credentials will be used when running an action would be very helpful. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
Hi @freakboy3742 , Thanks for this feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration. Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
One of the things GitHub Actions provides is the full payload for the event that triggered the workflow run and you can access that payload using the ${{ }} syntax. As mentioned in the context document you can access the event payload through the github context. You can navigate into the contents of the JSON object from the event payload by simply accessing the property. The pull_request event: https://developer.github.com/v3/activity/events/types/#pullrequestevent For example, to get the pull request number you would use ${{ github.event.number }}. To get the head sha you would use ${{ github.event.pull_request.head.sha }} As for different users for different workflows I am not sure I have a great solution right now. It is something we will have to think about. |
Beta Was this translation helpful? Give feedback.
-
|
@chrispatThanks - very helpful! It was surprising to me that this detail wasn’t available; nice to see it was an oversight on my part. By way of follow up suggestion: I think my oversight stemmed from the fact that the connection from the documentation that describes the context data (which I *did* find) to the documentation for the structure of the event data wasn’t entirely clear. The “event description” in the table at https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events points to https://developer.github.com/v3/pulls/ (which is a very high level description of interacting with pull requests) rather than https://developer.github.com/v3/activity/events/types/#pullrequestevent which is a direct description of the event that will be received. It appears that this is a common pattern in that table; the link (if provided) is to a description of an API endpoint that would cause the action, rather than the definition of the event that will be received. Might I suggest updating the links in that table to point at the relevant event definition, rather than the API endpoint? Or adding a separate column with a link to the event data definition? |
Beta Was this translation helpful? Give feedback.
@freakboy3742
One of the things GitHub Actions provides is the full payload for the event that triggered the workflow run and you can access that payload using the ${{ }} syntax. As mentioned in the context document you can access the event payload through the github context. You can navigate into the contents of the JSON object from the event payload by simply accessing the property.
The pull_request event: https://developer.github.com/v3/activity/events/types/#pullrequestevent
For example, to get the pull request number you would use ${{ github.event.number }}. To get the head sha you would use ${{ github.event.pull_request.head.sha }}
As for different users for different workflows …