actions / labeler

An action for automatically labelling pull requests
MIT License
1.98k stars 418 forks source link

Support labeling based on the pull request/commit title and messages #55

Open XVilka opened 4 years ago

XVilka commented 4 years ago

To apply the label based on the pattern match in one of the fields in:

austince commented 3 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*']
          }
        ]
      }
    }
  ]
  // ...
}
ssbarnea commented 3 years ago

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.

felipefrancisco commented 1 year ago

+1

marekpeszt commented 1 year ago

+1

merklefruit commented 1 year ago

+1

silasdavis commented 1 year ago

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.

phun-ky commented 1 year ago

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

kalvarez2 commented 1 year ago

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?

Jaskowicz1 commented 1 year ago

I like that, would be extremely useful!

kalvarez2 commented 1 year ago

@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

sschuberth commented 10 months ago

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.

mofosyne commented 5 months ago

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.