Inconsistent "on: issue" behaviour

Not quite sure where to post this, but

on:
  issues:
    types: [milestoned]

will trigger a workflow on master branch when I milestone a pull request. I would expect that

on:
  issues:
    types: [labeled]

would likewise trigger a workflow on master when labelling a PR, but it will only trigger on a real issue.

Overall I’m struggling understanding from the docs whether the workflow get’s triggered on the PR fork or master

The issues event will only trigger a workflow run if the workflow file is on the master or default branch, and it will run on the last commit on default branch.

https://help.github.com/en/actions/reference/events-that-trigger-workflows#issues-event-issues

This should apply to all types of issues labels. If you’re seeing a different scenario, are you able to provide a public repository as an example?

Sure, https://github.com/andrzejnovak/test_actions/actions - ignore PR#1 I put wrong names.

Workflows live in master, PR is an unrelated dummy file.

on:
  issues:
    types: [labeled]

doesn’t trigger when labelling the PR, but triggers when labelling an issue

on:
  issues:
    types: [milestoned]

triggers for both issue and PR, as it should iiuc since PR is a subset of issue.

@andrzejnovak
Thank you for pointing this problem . I have created an issue in our internal channel to confirm the behavior of labeled type of issues event. I will keep you updated.
Currently , you could add both issue and pull_request events as a workaround.

 on:
  issues:
    types: [labeled]
  pull_request:
    types: [labeled]

Thanks, though the workaround does not work for me.
on: issue triggers on master, while on: pull_request triggers on the PR branch. I need it to trigger on master correctly to have access to tokens.

@yanjingzhu any update on this?

@andrzejnovak
https://help.github.com/en/actions/reference/events-that-trigger-workflows#label-event-label is this what you are looking for?

@yaananth No this will not trigger a workflow when adding a label on a PR. This is currently possible for a milestone via on: issues: types: [milestoned] but not with on: issues: types: [labeled]. It doesn’t seem from the docs that this difference in treatment should exist, looks like a bug.

bump? (post must be longer than 20 chars)

@yanjingzhu @github-support Hi guys any updates, would I get faster feedback if I submitted a bug report?

@andrzejnovak Sorry for the delay response. GitHub engineering team has realized this inconsistent behavior of labeled and milestoned operations. They have added this to the backlog to get this fixed up.

As you said :

I need it to trigger on master correctly to have access to tokens.

I check the webhook event when I edit label in pull request. There is only a pull_request event happened currently.
What about you specify the default branch as the ref in actions/checkout step?
If this could not work, could you please share a detail scenario of how to access to tokens? Let me check whether there is a workaround for you.
And you could also contact GitHub Support directly and sharing your requirement in the ticket. This will help improve the priority of this problem. Thank you for your contribution to GitHub Actions.

1 Like

@yanjingzhu Thanks for getting back to me. Indeed that’s the idea. The info in the on: issue: labelled request should allow the workflow which is running in master (permissions) to execute stuff related to the PR, like comments etc. This is not currently possible because on: pull_request runs on the fork unlike on: issue.

The current best workaround I was able to come up with is either abusing milestoned/watch events as unspecific triggers or a cron job running on master, which is kind of an ugly solution as well.

@andrzejnovak GitHub engineering team are working on a new event: “pull_request_target” event . This will trigger on the PR target branch, such as master. It will be published to public in the near future. Please keep an eye on the changelog.

2 Likes

@yanjingzhu Any update of possible eta? Thanks :slight_smile:

The pull_request_target event is planned to be shown to the Public on 07/31/2020.

1 Like