CI(labeler): Disable sync-labels that removes labels and pin action #3495
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When this workflow was introduced, I suggested we try using the sync-labels option, that removes labels if files that were previously matching filters aren't matching anymore, like when some changes are reverted. We would have the time to refine our label-matching rules after merging. After a couple months of using this action (since end of December/beginning of January), I didn't see as much of pull requests where files were initially changed and were finally reverted and that it would have changed the labels of the PR. However, I saw multiple times PRs where manually added labels were removed, sometimes multiple times after each commit, which is a bit less intuitive. Each time I saw labels removed, I tried to think if an adjustment to the label matching patterns would do the trick, but most often not. A recent example is with the recent @HuidaeCho's PRs: a GUI and raster specific bug that needs to be fixed in files that match another section, like display.
So, for the time being, I suggest to turn that option back off, its default value. I left the line there set to false instead of removing it as a reminder that we tried it, in case the default changes in the future. (If in the future the behaviour is more adapted, we could try it again).
It is now our job (us PR reviewers) to remove unnecessary labels if less files are changed in a PR than it has previously had when the labeler workflow ran.