flag unlabeled PRs with wildcard label #134
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #74
馃憢 Hi there,
I'm working on a project with a distributed team and we were looking for a way to generate changelogs/releases easier. The challenge we ran up against is essentially the problem identified in #74.
To address this, I made a change to identify any commits that didn't have a label from the config with a "wildcard label" (name taken from the linked issue). I have details on how it works in the README.md. I wanted to share my approach to see if it is something you feel is useful before I go forward with writing test and whatnot 馃槂
Result
Example from my testing:
Approach
I have details on my thought process in my fork, but essentially I felt the following was a good workflow:
wildcardLabel
is optional and by default it has no value.labels
along with a heading.^ At first writing it in
labels
felt like duplication of effort. However, I realized the value forwildcardLabel
could match a real label being used on GitHub to act as a safeguard for workflows where people are identifying PRs that need labeling. e.g. You have a typical workflow to label things on GitHub withunlabeled
orfor triage
until you know whether the change is going to be a breaking one. Incase that PR never gets "properly labeled" before merging, you'd want a warning in place before you make that next release.