Skip to content

Comment on issues when @rustbot label is given an invalid label #1610

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

Merged
merged 1 commit into from
Apr 24, 2022

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Apr 13, 2022

Previously, the label was just silently ignored, along with all other labels
in the same command. This tells the user what went wrong, and also adds all valid labels.

I'm not sure how to test this :(

@Mark-Simulacrum
Copy link
Member

A couple notes:

  • I don't think this belongs in the github.rs API -- if we want to provide metadata, that should be returned to the caller. We can have a helper function which puts a comment, too, but I'd prefer to avoid add_labels having side effects beyond adding labels :)
  • No need to test, we typically just merge and test in production for triagebot. Not critical enough to worry about.

I'm also a little uncertain about the approach. I think historically the choice to silently eat bad labels has been semi-intentional, as it means that we can avoid lots of comments if you edit a comment trying to fix any typos you made. This definitely prioritizes "advanced" users over newcomers though; which might well be the wrong tradeoff.

I'm not sure what a good way to thread the needle on that tradeoff is. It seems like either way we're not really delivering a great experience.

Regardless, my inclination is to make label adding atomic, like we did before. I think it's much less confusing what to do when we've failed to add in general, and prevents awkwardness around label-based triggering on "half" of the labels you added (since that triggering can have exclusions).

@jyn514
Copy link
Member Author

jyn514 commented Apr 13, 2022

Regardless, my inclination is to make label adding atomic, like we did before.

👍 This makes sense to me and will simplify moving the changes out of github.rs. I'll try and get to it this week.

@jyn514
Copy link
Member Author

jyn514 commented Apr 14, 2022

Ah, I just realized that add_labels is used in many places besides autolabel - the tradeoffs are making more sense to me now. I changed this to return an error on unknown labels that only autolabel checks for, and all other commands just bubble up to the top-level as a log. I also ensured that no labels are added if unknown labels are present. Note that this is not quite the same as "atomic" because autolabel calls add_labels(); remove_labels(); right after each other, but it matches the previous behavior.

Previously, the label was just silently ignored, along with all other labels
in the same command. This tells the user what went wrong, and also adds all valid labels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants