Fix PR labeling and generate nightly build notes from them. #4077
Conversation
This configures the nightly build to generate release notes and provides a template for organizing them. The organization is done through labeling of PRs and categorizing them based on those labels. I've tried to provide a rough categorization that seems reasonable for folks. While doing this I looked at our PR labeling and found a few bugs that were preventing many labels form being attached. I've fixed those and significantly expanded the coverage of file-based labeling. I've also added code to do author-based labeling for automated PRs so those can be separated out from human PRs.
| - id: proposal | ||
| if: steps.filter.outputs.proposal == 'true' | ||
| run: | | ||
| gh pr edit "${PR}" --add-label "proposal" | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| PR: ${{ github.event.pull_request.html_url }} |
There was a problem hiding this comment.
Proposals should be getting labels from the proposal_labeled and proposal_ready flows, are you seeing issues with them? I'm wary of having multiple actions trying to set labels.
There was a problem hiding this comment.
So, I believe that proposal_labeled.yaml only handles keeping updates between the draft, rfc, accepted, and declined labels consistent. And proposal_ready.yaml only handles a PR that has some proposal label getting marked as ready_for_review, and triggering the proposal rfc label for that. A human has to apply the proposal (or proposal draft) label first.
And those workflows don't seem the right place to do this proposal labeling as we really want to trigger on the paths here and more events. So I think this is a reasonably clean breakdown of logic based on the events that trigger workflows.
I can try to merge all the proposal label management into a single workflow if you want, but we already have 3 actions setting labels, and so I don't think this PR is making things much worse there.
There was a problem hiding this comment.
So, new_proposal.py adds the proposal label. Should PRs that don't use the new_proposal script that add files here generally be marked as proposals? That will probably include non-proposal things.
There was a problem hiding this comment.
As discussed, hopefully this actually matches what we want and gives coverage for proposals that aren't created with the script.
I've also added a comment to highlight how it is different.
| - id: proposal | ||
| if: steps.filter.outputs.proposal == 'true' | ||
| run: | | ||
| gh pr edit "${PR}" --add-label "proposal" | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| PR: ${{ github.event.pull_request.html_url }} |
There was a problem hiding this comment.
So, I believe that proposal_labeled.yaml only handles keeping updates between the draft, rfc, accepted, and declined labels consistent. And proposal_ready.yaml only handles a PR that has some proposal label getting marked as ready_for_review, and triggering the proposal rfc label for that. A human has to apply the proposal (or proposal draft) label first.
And those workflows don't seem the right place to do this proposal labeling as we really want to trigger on the paths here and more events. So I think this is a reasonably clean breakdown of logic based on the events that trigger workflows.
I can try to merge all the proposal label management into a single workflow if you want, but we already have 3 actions setting labels, and so I don't think this PR is making things much worse there.
| - 'proposal/scripts/**' | ||
| - 'scripts/**' | ||
| - 'testing/**' | ||
| - 'third_party/**' | ||
| - 'utils/**' | ||
| proposal: | ||
| - added: 'proposals/*' |
There was a problem hiding this comment.
Should this exclude proposals/scripts?
There was a problem hiding this comment.
I believe it does because it only is one *, so this should only match added files (or new directories) directly under proposals.
| - id: proposal | ||
| if: steps.filter.outputs.proposal == 'true' | ||
| run: | | ||
| gh pr edit "${PR}" --add-label "proposal" | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| PR: ${{ github.event.pull_request.html_url }} |
There was a problem hiding this comment.
So, new_proposal.py adds the proposal label. Should PRs that don't use the new_proposal script that add files here generally be marked as proposals? That will probably include non-proposal things.
|
Thanks, merging. That said, if any of the comments need improving, happy to do that in a follow-up! |
This configures the nightly build to generate release notes and provides a template for organizing them. The organization is done through labeling of PRs and categorizing them based on those labels. I've tried to provide a rough categorization that seems reasonable for folks.
While doing this I looked at our PR labeling and found a few bugs that were preventing many labels form being attached. I've fixed those and significantly expanded the coverage of file-based labeling. I've also added code to do author-based labeling for automated PRs so those can be separated out from human PRs.