Open victornvg opened 3 years ago
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.
@joerick for example
I create PR - 1
with label minor
, when trigger github action on this PR - 1
, joerick/pr-labels-action@v1.0.6
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/pr-labels-action@v1.0.6
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/pr-labels-action@v1.0.6
can return the correct label from merged PR - 1
(minor
in this case) when pushing PR - 1
to default branch.
@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.
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
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