Open XVilka opened 4 years ago
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 pr: { body?: StringOrMatchConfig[], title?: StringOrMatchConfig[] }
?
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
+1
+1
Can we also have the ability to specifically label based on git commit footers, e.g.
chore(foo): my fix
Risk: D
Urgency: 2
Signed-off-by: Silas Davis <silas@example.com>
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:
test: 💍 Remove test for untestable code, due to environment
would then add a test
label
Hi, would it be acceptable to instead of the structured way, "simply" to add an optional prefix on the blob?
For example:
label1:
- "body:#potato"
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? https://github.com/actions/labeler/pull/688
Release Drafter already has the auto-labeling feature, see https://github.com/release-drafter/release-drafter#autolabeler
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: