I want to subscribe to notifications about PRs with a specific label, release.
When I set up the subscription for all PRs, i.e., with
/github subscribe list features
returning
Subscribed to the following repositories
myorg/myrepo
pulls
I do get notifications for all PRs.
Now, I add a filter for my label:
/github subscribe myorg/myrepo +label:release
and I get confirmation like this:
This channel will get notifications from myorg/myrepo for:
pulls, required-label: 'release'
Now, when I create a PR with that label manually, the channel does get the notification, as expected.
However, the PRs with that label are created from within a GitHub Actions workflow; specifically, using this action, which under the hood uses hub with a command like
hub pull-request -b destination-branch -h source-branch -l release
and a PR created from that action does not trigger a notification. When it is merged, it does trigger a notification.
The only difference I can see between a PR created by myself and the action is that for mine, the label seems to be added before automated code owner reviews are assigned:

whereas for the action-generated PR, it's the other way around:

Is the action somehow adding the label too late, and the notification is only triggered if the PR is created already having the label, or is this a bug?
Thanks for opening this issue! If you would like to help implement an improvement, read more about contributing and consider submitting a pull request.
@bewuethr
Is the action somehow adding the label too late, and the notification is only triggered if the PR is created already having the label
This is probably the reason.
Some solutions I thought of would to try re-ordering the steps in the Github Action.
Or, you can try to use two different Github Actions: one to create a labeled PR, and then another to request the review.
@chenbobby
This is probably the reason.
Some solutions I thought of would to try re-ordering the steps in the Github Action.
Or, you can try to use two different Github Actions: one to create a labeled PR, and then another to request the review.
Thank you for the suggestions!
I'm going to try and use gh (the GitHub CLI) directly to create the PR instead of the action that uses hub under the hood; maybe it uses the API differently. Review requests are triggered via code owners, so I can't really prevent those from being assigned immediately when the PR is created, unfortunately.
I'll report back if I find something!
Creating a PR as a draft first and then marking it as ready does work to trigger the notification; using gh from a GitHub Actions workflow isn't the straightforward fix, though, as it fails on exactly the "mark PR as ready" step, see cli/cli#1314.
@bewuethr Thanks for the detailed writeup, and I'm sorry that all these stubtle inconsistencies are causing you so much trouble. 馃檱
Now, when I create a PR with that label _manually_, the channel _does_ get the notification, as expected.
The difference between creating a PR with labels in the web UI and doing so via hub/gh (or anything that uses the API, really) is that an API client assigns labels in a separate request, since there exist no APIs (REST nor GraphQL) to create a PR with labels immediately. One consequence that you are experiencing is that the PR creation event will be reported to integrations as if the PR was created without labels, since labels only got added "later".
I'm not sure what the solution should be. Ideally, the createPullRequest GraphQL mutation would support assigning labels like the createIssue mutation does (I've requested this feature from the Pull Requests team, and they have it on their radar). As a workaround for the current situations, integrations could make an additional request after they get a PR create event to verify the latest state of its labels.
I'm seeing a type of this error where a github action adds a label, but the pull request notification posted to a public channel does not include the label.
This is inconvenient, because people take action based on which labels are present or not, and use this channel as a feed of activity when prs are opened.
Most helpful comment
@bewuethr Thanks for the detailed writeup, and I'm sorry that all these stubtle inconsistencies are causing you so much trouble. 馃檱
The difference between creating a PR with labels in the web UI and doing so via hub/gh (or anything that uses the API, really) is that an API client assigns labels in a separate request, since there exist no APIs (REST nor GraphQL) to create a PR with labels immediately. One consequence that you are experiencing is that the PR creation event will be reported to integrations as if the PR was created without labels, since labels only got added "later".
I'm not sure what the solution should be. Ideally, the
createPullRequestGraphQL mutation would support assigning labels like thecreateIssuemutation does (I've requested this feature from the Pull Requests team, and they have it on their radar). As a workaround for the current situations, integrations could make an additional request after they get a PR create event to verify the latest state of its labels.