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

How to only add label, not remove when PR is opened? #112

Closed
pllim opened this issue Nov 11, 2020 · 6 comments · Fixed by #480
Closed

How to only add label, not remove when PR is opened? #112

pllim opened this issue Nov 11, 2020 · 6 comments · Fixed by #480
Labels
bug Something isn't working

Comments

@pllim
Copy link
Contributor

pllim commented Nov 11, 2020

I have a labeler action set up for when PR is opened, using all your default settings. The labeler YAML is set up as such (relevant parts listed below):

Docs:
  - docs/*

coordinates:
  - '**/coordinates/**/*'

When astropy/astropy#11023 was opened, the only file changed was docs/coordinates/apply_space_motion.rst. By the labeler logic, it should apply Docs and coordinates.

However, the PR author already manually applied Docs label at creation time. As a result, the labeler ended up removing the Docs label. Is this a bug? How do I tell it to simply no-op when a label that should be applied is already there?

Screenshot 2020-11-10 234620

Hope you can help and thanks for such a useful action!

@pllim
Copy link
Contributor Author

pllim commented Nov 11, 2020

Strangely enough, accidental removal did not happen for astropy/astropy#11028 when the file changed was only docs/conf.py and Docs label was also applied manually when PR was opened.

Screenshot 2020-11-11 101002

Screenshot 2020-11-11 101107

(The Action ran successfully but it was a no-op, as expected.)

@makecir
Copy link

makecir commented Feb 2, 2021

There hasn't been much progress in the conversation, but I also want to solve this problem.
By removing the manually attached tags, the benefits gained by labelar are diminished.

@ericdallo
Copy link

Any news here?

@adam-azarchs
Copy link
Contributor

It looks like the problem is

const syncLabels = !!core.getInput("sync-labels", { required: false });

which is not correct because the default value is "false", and !!"false" == true.

@adam-azarchs
Copy link
Contributor

Confirmed, you can work around this bug by setting

sync-labels: ''

in your workflow.

Gustry added a commit to 3liz/lizmap-web-client that referenced this issue Apr 11, 2022
@liverpool1026
Copy link

Confirmed, you can work around this bug by setting

sync-labels: ''

in your workflow.

Thanks for this, can also confirm this works in v4. Any plans to fix this properly in the next version?

adam-azarchs added a commit to adam-azarchs/labeler that referenced this issue Jan 11, 2023
Contrary to the assumptions made in the unit tests, core.getInput
always returns a string, and !!'false' is true.

Fixes actions#112
adam-azarchs added a commit to adam-azarchs/labeler that referenced this issue Jan 18, 2023
Contrary to the assumptions made in the unit tests, core.getInput
always returns a string, and !!'false' is true.

Also updates the unit test to reduce changes of regressions by ensuring
that the mocked getInput returns a string, as it would in production.

Fixes actions#112

Make sure test catches regressions.
rickstaa added a commit to rickstaa/github-emoji-picker that referenced this issue Feb 7, 2023
This prevents the removal of labels that occurs due to a bug in 'actions/labeler' (see actions/labeler#112).
rickstaa added a commit to rickstaa/github-emoji-picker that referenced this issue Feb 7, 2023
This prevents the removal of labels that occurs due to a bug in 'actions/labeler' (see actions/labeler#112).
MaksimZhukov pushed a commit that referenced this issue Mar 23, 2023
* fix: correct reading of sync-labels input.

Contrary to the assumptions made in the unit tests, core.getInput
always returns a string, and !!'false' is true.

Also updates the unit test to reduce changes of regressions by ensuring
that the mocked getInput returns a string, as it would in production.

Fixes #112

Make sure test catches regressions.

* Rebuild dist/index.js.
CaseyHillers pushed a commit to flutter/flutter that referenced this issue Jul 14, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this issue Jul 18, 2023
LouiseHsu pushed a commit to LouiseHsu/flutter that referenced this issue Jul 31, 2023
Czaki added a commit to napari/napari that referenced this issue Oct 18, 2023
# Description

In PR #6328 I have added an automatic maintenance label when something
is edited pre-commit. But I wrongly understand actions/lableler
documentation and thought that the bug was fixed, that is true, but it
is fixed in v5 branch, not backported to v4.

v5 has been from a long time (since May) in the release process.

actions/labeler#112
auto-submit bot pushed a commit to flutter/flutter that referenced this issue Dec 4, 2023
actions/labeler#112 has been fixed, and now requires boolean to be used. 

Related infra issue that this fixes: #139511
auto-submit bot added a commit to flutter/flutter that referenced this issue Dec 5, 2023
Reverts #139516
Initiated by: godofredoc
This change reverts the following previous change:
Original Description:
actions/labeler#112 has been fixed, and now requires boolean to be used. 

Related infra issue that this fixes: #139511
Gibbo97 pushed a commit to Gibbo97/flutter that referenced this issue Dec 13, 2023
Reverts flutter#139516
Initiated by: godofredoc
This change reverts the following previous change:
Original Description:
actions/labeler#112 has been fixed, and now requires boolean to be used. 

Related infra issue that this fixes: flutter#139511
nyalldawson added a commit to qgis/QGIS that referenced this issue Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants