-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
chore: remove pr labeler requirement #10081
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should still keep this job as an enforcement in case the other one fails, as well as if the changes don't result in that one automatically applying a label.
You will get no green checkmark automatically though |
The two don't work together, the label gets applied too late and then the label check job doesn't run because it won't be triggered by the bot adding a label. |
Ah, because the workflow_run won't be triggered due to that annoying loop prevention, ugh... Any ideas for how we can work around that? If we can I think it would still be worth having this enforcement. As an alternative, maybe the enforcement can be baked into the other job? |
We talked about it earlier and really it's not a big deal if it doesn't get applied, we can always sort any missing a label when we come to making the release notes |
Definitely true, but IMO it's much easier to do that when the context of the PR is still fresh. |
Going to test without it and see how it goes
workflow_run: | ||
workflows: ["Pull Request Labeler"] | ||
types: | ||
- completed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This very condition was supposed to re-run the "Enforce PR labels" after "Pull Request Labeler". At least, that's how it worked in my fork.
So what's different? In the PR discussion a loop prevention is mentioned. Does that prevent the desired behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure really, I think we basically decided it wasn't worth investigating when the labels aren't actually "mandatory" they're just a really nice help and the other action should catch most cases anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. When I implemented it this way, I felt a little dirty about the dependency across workflows. Less complexity is a good thing, too.
Remove pr label enforcing job since it is now done through CI