Support getting labels when merging PR into default branch

[victornvg]

Currently I use this github action and it work well in the PR, but when I have workflow that is triggered on push event like this

This error will appear.

Can you also support this case? getting label base on the push event to default branch

[joerick]

Hi Victor! I'm not sure I understand. Do branches have labels? Where are they? Or do you mean that the extension should return an empty set of labels when building a branch?

…

Sent from my phone

On 6 Sep 2021, at 09:38, Victor Nguyen ***@***.***> wrote:  Currently I use this github action and it work well in the PR, but when I have workflow that is triggered on push event like this This error will appear. Can you also support this case? getting label base on the push event to default branch — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[victornvg]

@joerick for example
I create PR - 1 with label minor, when trigger github action on this PR - 1, joerick/[email protected] will return the correct label minor. Everything works fine.
But when I merge this PR - 1 to default branch (main in this case), and I have the workflow trigger push event on main, joerick/[email protected] won't return the label from merged PR - 1 (only show Not a pull request)

This is not a bug. Just a request to support another case, that joerick/[email protected] can return the correct label from merged PR - 1 (minor in this case) when pushing PR - 1 to default branch.

[weibullguy]

@victornvg I too was wanting to do this, but I don't think it's easily done using the REST API. A push is a commit, so the payload when using the REST API has no information related to the PR. It's distinctly possible I have no idea what I'm talking about, but you can read about commits (pushes) here --> https://docs.github.com/en/rest/reference/commits#get-a-commit There is an example of the returned payload and you can see there is no information related to the PR. A PR requires a push, but a push doesn't require a PR, so it makes some intuitive sense.

It looks like you might be able to work backwards to the PR using the commit's ref. I don't know how difficult that would be, but it seems mildly convoluted to me. Again, it's distinctly possible I have no idea what I'm talking about.

That said, it looks like the GraphQL API makes this easier. One of the fields in the commit object is associatedPullRequests. You can see that here --> https://docs.github.com/en/graphql/reference/objects#commit If you poke around a bit in the GraphQL API documentation, you'll see there is a labels field associated with the PullRequest object.

[deejgregor]

I suspect you can accomplish what you are looking for by matching on a pull request of type closed that has been merged.

For example, this on block:

on:
  pull_request:
    types:
    - closed
    branches:
    - main

And in each job, make sure you match on pull requests that have been merged (because you probably won't want to match pull requests that have been closed without merging):

if: github.event.pull_request.merged == true

See this for more information: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges