This action already has the features and stability for the original use case I wrote it for, and I'm not looking to add to it at this time. If you're looking for additional features, there's an active fork at videndum/super-labeler-action.
A superpowered issue and pull request labeler for Github Actions.
Super Labeler allows you to declaratively define your repository's labels, and when to apply them, in a config file that's checked into your repository.
Create a new Github Actions workflow at .github/workflows/label.yml:
Click to show example workflow
Note: actions/checkout must be run first so that the labeler action can find your config file.
on:
issues: [opened, edited, closed, reopened]
pull_request:
types: [opened, edited, closed, reopened, ready_for_review, synchronize]
jobs:
label:
runs-on: ubuntu-latest
name: Label issues and pull requests
steps:
- uses: actions/checkout@v2
- uses: IvanFon/super-labeler-action@v1
with:
github-token: '${{ secrets.GITHUB_TOKEN }}'Now create the labeler config file at .github/labels.json:
Click here to show example config
{
"labels": {
"example": {
"name": "example",
"colour": "#00ff00",
"description": "Example label"
}
},
"issue": {
"example": {
"requires": 2,
"conditions": [
{
"type": "titleMatches",
"pattern": "example"
},
{
"type": "isOpen"
}
]
}
},
"pr": {
"example": {
"requires": 1,
"conditions": [
{
"type": "isDraft",
"value": false
}
]
}
}
}Be sure that Github Actions is enabled for in your repository's settings. Super Labeler will now run on your issues and pull requests.
Whenever Super Labeler runs, it will first add and update your repository's labels to match your config. Then it will go through each label's conditions to determine if it should apply or remove that label.
Each label has a list of conditions that must be met for it to be applied. You must specify the minimum number of conditions that must be met for the label to be applied.
Each label has a key, which can be different from it's name. This key should be in plaintext, and will be used to refer to the given label when defining your conditions. For example, given the following labels definition:
{
"labels": {
"bugfix": {
"name": "Bugfix! 🎉",
"colour": "ff0000",
"description": "Fixes a bug."
}
}
}While the label's name, which will be displayed on Github, is "Bugfix! 🎉", to be able to easily refer to it from our conditions, we would use it's key, which is just bugfix:
{
"pr": {
"bugfix": {
"requires": 1,
"conditions": [
{
"type": "branchMatches",
"pattern": "^bugfix"
}
]
}
}
}The config object contains three keys:
labels: Your repository's labels, which will be automatically created and updated by Super Labelerissue: Labels to apply to issues, and their conditionspr: Labels to apply to pull requests, and their conditions
Take a look at the examples in this file to get a feel for how to configure it. The below Typescript interface, which is used by this action, may also be helpful:
Click to show Typescript config interface
interface Config {
labels: {
[key: string]: {
name: string,
colour: string,
description: string,
},
};
issue: {
[key: string]: {
requires: number,
conditions: IssueCondition[],
},
};
pr: {
[key: string]: {
requires: number,
conditions: PRCondition[],
},
};
}Many conditions use regular expressions (usually with a pattern parameter).
Since these regular expressions are passed in through JSON strings, there are
some things to pay attention to.
Special characters must be double escaped: pattern: "\\W+$" is equivalent to the Regex: /\W+$/.
If you want to use flags, use the following format: pattern: "/^wip:/i" is equivalent to the Regex: /^wip:/i.
Applies to: pull requests
Checks if branch name matches a Regex pattern.
Example:
{
"type": "branchMatches",
"pattern": "^bugfix\\/"
}Applies to: issues and pull requests
Checks if an issue or pull request's creator's username matches a Regex pattern.
Example:
{
"type": "creatorMatches",
"pattern": "^foo"
}Applies to: issues and pull requests
Checks if an issue or pull request's description matches a Regex pattern.
Example:
{
"type": "descriptionMatches",
"pattern": "foo.*bar"
}Applies to: pull requests
Checks if the files modified in the pull request match a glob.
Globs are matched using the minimatch library.
Example:
{
"type": "filesMatch",
"glob": "src/foo/**/*"
}Applies to: pull requests
Checks if a pull request is a draft.
Example:
{
"type": "isDraft",
"value": true
}Applies to: issues and pull requests
Checks if an issue or pull request is locked.
Example:
{
"type": "isLocked",
"value": true
}Applies to: issues and pull requests
Checks if an issue or pull request is open or closed.
Example:
{
"type": "isOpen",
"value": true
}Applies to: issues and pull requests
Checks if an issue or pull request's title matches a Regex pattern.
Example:
{
"type": "titleMatches",
"pattern": "/^wip:/i"
}