Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to preserve manually added labels #624

Open
EvieSchwarzIntel opened this issue Jul 19, 2023 · 9 comments
Open

Option to preserve manually added labels #624

EvieSchwarzIntel opened this issue Jul 19, 2023 · 9 comments
Labels
feature request New feature or request to improve the current logic

Comments

@EvieSchwarzIntel
Copy link

EvieSchwarzIntel commented Jul 19, 2023

Description:
I would like add an option to:

  • Add a label if files are changed, defined in labeller.yml (default behaviour already)
  • Don't remove label, if labeller detects that files "belonging to the label" defined in labeller.yml, are changed

sync-labels: does not work in this case.

Could call the option "preserve-labels" or similar.

Description (usecase):
Suppose we have a repo with 2 generations (versions) of a project.
The src code for generations are in 2 different directories.
Some common code is shared.

I define the labeller like so:
labeller.yml:

GENERATION0_LABELLER_LABEL:
- 'common_files/.**'
- 'generation0_files/.**'

GENERATION1_LABELLER_LABEL:
- 'common_files/.**'
- 'generation1_files/.**'

There are cases where, regardless of the files changed, I want to run tests for both generations.
So I apply the label "GENERATION1_LABELLER_LABEL".
The labeller sees that I haven't changed files in "- 'common_files/.' or 'generation1_files/.'.
It removes the label.

Justification:
Currently we require 2 labels to get this to run.
GENERATION0_LABELLER_LABEL
GENERATION1_LABELLER_LABEL

GENERATION0_MANUAL_LABEL
GENERATION1_MANUAL_LABEL

Are you willing to submit a PR?
Not likely, but a possibility if complexity is low

@EvieSchwarzIntel EvieSchwarzIntel added feature request New feature or request to improve the current logic needs triage labels Jul 19, 2023
@MaksimZhukov
Copy link
Contributor

Hello @EvieSchwarzIntel! Thank you for the feature request!
We will consider adding this functionality!

@EvieSchwarzIntel
Copy link
Author

Hello @EvieSchwarzIntel! Thank you for the feature request! We will consider adding this functionality!

Great, thank you! What would be the estimated complexity in implementing this?

@MaksimZhukov
Copy link
Contributor

Could you please describe your use case in a little more detail?
My understanding is that you would like to add some labels without using the labeler action and don't want the action to remove them if they don't match the globs. Is it right?

The action only manages the labels that are specified in the configuration file. If you want to manage these labels yourself, why do you need to add them to the labeler config file? If you want to add labels in two ways and the action removes them, maybe it is better to change the glob patterns for those labels or create separate labels that will suit your needs? It seems to me that you have labels with an ambiguous non-obvious meaning.

Also could you please clarify why the sync-labels input is not an option for you?

@EvieSchwarzIntel
Copy link
Author

EvieSchwarzIntel commented Aug 11, 2023

My understanding is that you would like to add some labels without using the labeler action and don't want the action to remove them if they don't match the globs. Is it right?

Yes

The action only manages the labels that are specified in the configuration file. If you want to manage these labels yourself, why do you need to add them to the labeler config file?

I'll describe 2 situations.

1. Failsafe

  • Human error means that the labeller might be misconfigured, misused etc.
  • What if we have a large pull-request the result is to be delivered to customers.. we want to manually run all labels/jobs to be sure?

Potential issues:

  • A huge pull request is opened. New files are added, the files are not added to the labeller config. This is missed. We want to manually add the label to ensure we are covered.
  • The labeller pattern is wrong or misconfigured. Changes made to the files are not picked up. We are suspicious of this, and need to add both labels to run CI manually

2. Running Coverage/performance/memcheck metrics:
What if we want to utilize CI to run coverage jobs on either or both generations?
Files don't neccessarily need be changed in both generations to do this.

If you want to add labels in two ways and the action removes them, maybe it is better to change the glob patterns for those labels or create separate labels that will suit your needs? It seems to me that you have labels with an ambiguous non-obvious meaning.
This is the work-around i'm using. It gets messy when you have more than 2 generations.

So you end up with these labels:

Labeller controlled labels:
GENERATION0_AUTO_LABELLER
GENERATION1_AUTO_LABELLER
GENERATION2_AUTO_LABELLER

Manually controlled labels:
GENERATION0_MANUAL_LABEL
GENERATION1_MANUAL_LABEL
GENERATION2_MANUAL_LABEL

Also could you please clarify why the sync-labels input is not an option for you?

Whether or not sync-lables is added, the following behaviour happens:
If labels are manually applied - the labeller will remove them.

@vmohir
Copy link

vmohir commented Aug 17, 2023

I have the same issue. sync-labels is false but the labeler still removes the labels. In my case, if file x is changed, I want to add the label x but I might also want to add this label even if the x file is not changed.

@wheelerlaw
Copy link

sync-labels: false appears to not be working anymore.

@MaksimZhukov
Copy link
Contributor

Hello @wheelerlaw!
Could you please create a new issue and provide us with repro steps?

@KapJI
Copy link

KapJI commented Nov 21, 2023

I don't think sync-labels ever worked in this case. It's actually pretty annoying when I add labels manually before submitting a PR and then labeler removes it. It's difficult or not possible at all to express complex rules using only any and all matchers.

@ksunden
Copy link

ksunden commented Mar 7, 2024

Should be able to query https://docs.github.com/en/rest/issues/events#list-issue-events and remove labels if and only if they were added by the github-actions[bot] user (may wish to filter by actor ID number or even potentially just all "type": "Bot" accounts, I guess

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

6 participants