Thanks. But in my case, the workflow is triggered by issuing a comment. Will this still work?

@zachliu,

Sure. When you add a comments on a PR, the issue_comment event is triggered. At this time, the issue_comment event is related to the PR.

Tip: On GitHub, pull request is considered as a type of issue, that’s way some event types of PR will be combined as the common issue events.

Great! I’ll give it a go and report back 🙏

@zachliu,
Okay. Please go ahead, and any update, feel free to tell me.

@zachliu,

EDIT:

When the workflow is triggered by the issue_comment event, the object will always be “github.event.issue”, so the author should be “github.event.issue.user.login”.

To determine if it is a PR, you can see if the “github.event.issue.pull_request” object exists.
for example:

- name: View PR author
  if: ${{ github.event.issue.pull_request }}
  run: echo "This PR is opened by ${{ github.event.issue.user.login }} ."

It’s a bit confusing now. Let me tell the story again:
If A opens a PR and triggers a workflow, it’s easy to get A’s username in the workflow
If B comments on A’s PR and triggers another workflow, how do I still get A’s username in this workflow?

Is it issue or issues in {{ github.event.issue.user.login }}? You meant issues right?
I can’t find issue under webhook events.

@zachliu,

No, I’m just saying the issue_comment event, not issues event.

As I mentioned above, pull request is considered as a type of issue, but a PR is not exactly same with an issue.

• There are some event types are the communal that can be used for both Pull requests and Issues, such as the issue_comment event.

• However, some event types only can be used for Pull requests, such as pull_request, pull_request_review, pull_request_review_comment and pull_request_target events.

• And some only for Issues (such as issues event).

Every time a workflow run is triggered, GitHub will generate the github context for this run. The github context contains many detailed information about the current workflow run, such as the repository name, the Git ref (branch, tag, commit SHA), the event that triggered the current run.

In your case, the information you require can be get from the github context. In your workflow, you also can print the whole context of the github context to the logs and view more details.

- name: Print GitHub context
  run: echo "$GITHUB_CONTEXT"
  env:
    GITHUB_CONTEXT: ${{ toJson(github) }}

The expressions “github.event.pull_request.user.login” and “github.event.issue.user.login” are used to get the values of the corresponding properties from the github context.

Great it works! Thank you!

When B comments on A’s PR, I can use {{ github.event.issue.user.login }} to get A’s username.

Now I am exploring {{ toJson(github) }} because I have another use case: when B merges A’s PR, I also want A’s username 😁

@zachliu,

when B merges A’s PR,

At this time, the event should be pull_request, and the activity type should be closed of the pull_request event. So, to get the the author of the PR, you need to use the expression “github.event.pull_request.user.login”.

Great it works!

Glad that the problems no longer bother you.
If you think my above explanations is helpful to you to solve your questions, maybe you can mark it as the solution of this topic. So that other people who have the similar questions can notice this when they are looking for answers. Thanks.

I have

on:
  push:
    branches:
      - master

but yeah, using pull_request + closed might be better

@zachliu,

If you want the workflow is triggered when the PR is merged, yes, using pull_request + closed is good.

on:
  pull_request:
    types: [closed]

Thank you so much!

Since I’m commenting/closing my own PRs all night, I couldn’t really verify the solution 😅 . I’ll double check tmr morning and mark the solution then.

Update: now I can confirm everything works fine. Thank you! @brightran