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:

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:

{
  "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.

• Getting Started
• Index
• How it Works
• Config File Format
• Using Regex Patterns
• Available Conditions
  • branchMatches
  • creatorMatches
  • descriptionMatches
  • filesMatch
  • isDraft
  • isLocked
  • isOpen
  • titleMatches

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 Labeler
• issue: Labels to apply to issues, and their conditions
• pr: 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:

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"
}

back to top