Merging `main` into PR causes incorrect labeling

[jamesmehorter]

Description: PR 1 is opened which has no changes matching patterns in labeler.yml, and as expected receives no labels, good. Meanwhile, PR 2 (which did match and receive a label, also good) is merged into main. Afterwards, merging main into PR 1 causes labeler to apply the same labels applied to PR 2, bad.

Action version: v4

Platform:

• [x] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [ ] Hosted
• [x] Self-hosted

Repro steps:

1. Create PR 1 which matches no rules in labeler.yml, confirm no labels are applied to PR 1
2. Create PR 2 which does match rules in labeler.yml, confirm labels are applied to PR 2
3. Merge PR 2 into main
4. Merge main into PR 1, observe that PR 2s labels are applied to PR 1

Expected behavior: Upon 4 above, no labels are applied to PR 1

Actual behavior: Upon 4 above, labels are applied to PR 1

[jamesmehorter]

I started to solve for this in our actions but thought I should post here first

[HarithaVattikuti]

Hello @jamesmehorter Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

[zzztimbo]

We are seeing a simliar issue as well.

[svrnm]

We see the same issue

Edit: another work around is restricting the activity types to opened and reopened and by that dropping synchronize, see here: "By default, a workflow only runs when a pull_request_target event's activity type is opened, synchronize, or reopened"

[suyashgaonkar]

Hi @jamesmehorter , we investigated the issue with provided details. After thorough investigation the workaround we recommend, is to avoid passing synchronize and closed values to the pull_request parameter which triggers the workflow. We recommend following code snippet as a solution.

on:  
  workflow_dispatch:
  pull_request: 
    types: [opened,reopened]

By default a workflow only runs when a pull_request event's activity type is opened, synchronize ,or reopened. Hence it would be essential to avoid the use of synchronize and closed pull request activity types as a value for the parameter. Kindly refer the following link for more information.

[suyashgaonkar]

Hi @jamesmehorter , We are awaiting for your response on the following issue, you can let us know incase of any queries.

[suyashgaonkar]

Hi @jamesmehorter , We are awaiting for your response, you can let us know if you have any queriers or the issue still exists.

[suyashgaonkar]

Hi, this issue has been inactive for some time. It seems that the issue may have been resolved or is no longer relevant. I will proceed to close this issue. Feel free to reach us out incase of any further updates. Thank you!

[wolfgangwalther]

This issue still persists. Avoiding the sychronize event is not going to help, because it will miss many valid cases, which should be labelled.

The approach outlined in https://github.com/actions/labeler/issues/784#issuecomment-2127854447, to make the job conditional on the commit message, is not going to work based on GHA documentation - because there is no head_commit event for pull_request events. It only exists for push.

It seems to me like this should really be solved by the labelers action - because nobody will ever want to have labels based on merge commits back from the base branch. The assumption when using this action is, that the labels will be created based on the diff of the overall PR, compared to the base branch. But with a merge commit coming in, somehow the changes in that commit on the base branch itself are considered.

Although, looking at the source code here ...:

https://github.com/actions/labeler/blob/6463cdb00ee92c05bec55dffc4e1fce250301945/src/changedFiles.ts#L30-L34

It looks to me like the changed files must be returned by GitHub's API like this?