-
Notifications
You must be signed in to change notification settings - Fork 414
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
Support labeling based on the pull request/commit title and messages #55
Comments
The commit-specific matching might be more work, as it would require fetching all the commits that are contained in the PR, but the PR title and body should be already available. What about adding a label config object item like Ex: # Add 'test' label to any change to *.spec.js files within the source dir
# or with a PR title that is in the form 'test:*'
# or with a PR body that contains the word 'test' but not 'bug'
test:
- src/**/*.spec.js
- pr:
title:
- 'test:*'
body:
- any: [ '*test*' ]
all: [ '*bug*' ] This could then be expanded to include the commits: # Add 'test' label to any change to *.spec.js files within the source dir
# or with a PR title that is in the form 'test:*'
# or with a PR body that contains the word 'test' but not 'bug'
# or has any commits with a title in the form 'test:*'
test:
- src/**/*.spec.js
- pr:
title:
- 'test:*'
body:
- any: [ '*test*' ]
all: [ '*bug*' ]
- commits:
title:
- 'test:*' In typescript, this could then be modeled like: export interface MatchConfig {
all?: string[];
any?: string[];
}
export type MatchConfigEntry = string | MatchConfig;
export interface PRConfigEntry {
title?: MatchConfigEntry[];
body?: MatchConfigEntry[];
}
export type ConfigEntry = MatchConfigEntry | { pr: PRConfigEntry };
export interface Config {
[label: string]: ConfigEntry[];
}
const config: Config = {
// ...
test: [
'src/**/*.spec.js',
{
pr: {
title: ['test:*'],
body: [
{
any: ['*test*'],
all: ['*bug*']
}
]
}
}
]
// ...
} |
Release Drafter already has the auto-labeling feature, see https://github.com/release-drafter/release-drafter#autolabeler Sadly, AFAIK, it does not have the ability to be used as a check that prevent a change from being merged if is missing the right labels. |
+1 |
2 similar comments
+1 |
+1 |
Can we also have the ability to specifically label based on git commit footers, e.g.
This would play nicely with conventional commits (https://www.conventionalcommits.org/en/v1.0.0/#specification), for example. |
Could this feature be expanded to let the labeler read the commit message, so for example, if a repo is following commitizen, we can tag PRs (and eventually issues), with the type of commit? for example:
would then add a |
Hi, would it be acceptable to instead of the structured way, "simply" to add an optional prefix on the blob? For example:
Would add the label "label1" if the body contains the string #potato Looking at the code, this would be simpler to add, and from the user experience point of view I think it works ok to? |
I like that, would be extremely useful! |
@MaksimZhukov should I make another for 5.0 branch? is there any hope that this will be merged to 4.0? |
No more lightweight / fitting comparison might be to https://github.com/fuxingloh/multi-labeler#features, tough. |
Heads up that someone did something similar https://github.com/Bhacaz/label-regex but I think it be more ideal if it's already part of actions/labeler to minimize the number of separate workflow required. |
To apply the label based on the pattern match in one of the fields in:
The text was updated successfully, but these errors were encountered: