auto label new PRs with type::feature and type::docs #943
Conversation
replicated-ci
added
type::docs
e3b0c442
added
type::chore
and removed
type::feature
| github-token: ${{ secrets.DOCS_GH_PAT }} | ||
| script: | | ||
| const labels = ['type::feature', 'type::docs'] | ||
| github.rest.issues.addLabels({ |
There was a problem hiding this comment.
Thanks @e3b0c442. Not sure I fully understood it though, would you mind clarifying it a bit? Is it going to add the same labels to all open issues ? Ah, this is a little bit confusing, seems like we are adding labels to the opened pull requests (on.pull_request.types: ["opened"]) but at the same time the function seems to be adding them to the issues (github.rest.issues.addLabels) instead. Are we adding or making sure the labels exist on open issues every time a pull request is opened ?
There was a problem hiding this comment.
Hey, no worries.
The on clause determines which events trigger the workflow, so in this case, it only runs when pull requests are opened.
In GitHub, pull requests are just issues with a special purpose, so we call the issue label API to add a label, with the issue (pull request) number coming from the context.
So yes, this workflow adds those labels only to pull requests, and only when they are initially opened; it will not run again for any PR after being opened.
There was a problem hiding this comment.
Thanks @e3b0c442 , that clarifies everything. Is this something we really want to do ? I mean, I bet we are going to start seeing PRs labeled as "feature" when they are "bugs" as less and less people stop even noticing labels ("green means all good").
There was a problem hiding this comment.
To @ricardomaraschini point, I'd say we should at a minimum default to adding type::docs(since this primarily our kURL docs site) and have the author of the PR consciously determine whether it's type::feature ∩ type::chore ∩ type::bug
There was a problem hiding this comment.
@paigecalvert needs to chime in here then. The ask was to reduce friction on the docs folks needing to manually add the labels. If 80% of the PRs to this repo are docs-only, then I think that makes sense. If the ratio is lower, we need to reconsider and come to an agreement between the two teams. We have already established that of the docs PRs, we hit that 80% threshold of feature/other.
There are some things that could be done if there's a clear delineation in the repo between docs and non-docs PRs as well; I can filter this workflow to a subset of paths in the repo, or we can look at fully splitting the repos so the teams can set their own policies.
There was a problem hiding this comment.
Thanks for the ping @e3b0c442. Yes, the ask here was to automatically apply these labels because:
There is a requirement that all PRs have to use a primary label, but the Docs team does not use the categories of "feature", "bug" or "chore" to classify the types of PRs in this repo. Those labels are relevant to code changes, but they don't really translate very well to how we would want to categorize updates to the docs. So, we figured, rather than having to manually add "feature" on every PR in order to just get the test to pass, we would ask to have it added automatically to save ourselves the extra step.
THAT SAID, if this creates issues for other teams, or if it could mess up the data for others, then we certainly would not want to do it. I know that Dalia also wants the docs repos to use the same labels as the dev repos, so perhaps it's better for me to make sure that she is bought in before we merge.
I do apologize for the confusion--we did not anticipate the back and forth this would bring about.
No description provided.