Advanced Issue Labeler is a GitHub Action that can automatically label issues based on user input. The idea for this project came from and was first introduced in @systemd/systemd. Systemd repository has a very active community with many issues to process. Automatic labeling helps with issue triaging.

Advanced Issue Labeler takes advantage of GitHub issue forms (special kind of issue templates) to provide a better developer experience by labeling issues based on provided input. It is currently possible to label issues based only on dropdowns.

Advanced Issue Labeler is expected to work in cooperation with @stefanbuck/github-issue-parser GitHub Action. Parser action provides JSON representation of the submitted issue, where KEYs represent IDs described in the issue-form YAML configuration. Issue labeler understands it and can label issues based on selected values from dropdown. Dropdown values could directly represent labels or be mapped to policy configuration for more complex labeling requirements.

• Ability to label issues based on issue form dropdown values
• Ability to specify policy for mapping specific keywords to labels
• Ability to exclude certain words from the labeling process (block-list)

The following example shows how to automatically label issues based on the severity that the user describes in issue form. In issue form, there is a defined dropdown listing all severity levels:

# ...

- type: dropdown
  id: severity
  attributes:
    label: Severity impact
    description: Please choose the severity of the impact of this issue.
    multiple: false
    options:
      - 'None'
      - 'Low'
      - 'Medium'
      - 'High'
      - 'Urgent'
      - 'Other'
  validations:
    required: true

# ...

Warning: It's essential to set the correct ID in issue-form

GitHub workflow that automatically marks issues with severity labels:

name: Issue labeler
on:
  issues:
    types: [ opened ]

jobs:
  label-component:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Parse issue form
        uses: stefanbuck/github-issue-parser@v3
        id: issue-parser
        with:
          template-path: .github/ISSUE_TEMPLATE/bug.yml

      - name: Set labels based on severity field
        uses: redhat-plumbers-in-action/advanced-issue-labeler@v2
        with:
          issue-form: ${{ steps.issue-parser.outputs.jsonString }}
          section: severity
          block-list: |
            None
            Other
          token: ${{ secrets.GITHUB_TOKEN }}

The following example shows how to automatically label issues based on animal types. In issue form, there is a defined dropdown listing all animals:

# ...

- type: dropdown
  id: animals
  attributes:
    label: Animals
    description: Please pick all animals you like.
    multiple: true
    options:
      - 'None'
      - '🦍 Gorilla'
      - '🐶 Dog'
      - '🐺 Wolf'
      - '🦊 Fox'
      - '🐴 Horse'
      - '🐓 Rooster'
      - '🐦 Bird'
      - '🐧 Penguin'
      - '🐸 Frog'
      - '🐬 Dolphin'
      - '🐡 Blowfish'
      - '🐟 Fish'
      - '🦈 Shark'
      - '🐛 Bug'
      - '🕷️ Spider'
      - '🐊 Crocodile'
      - 'other'
  validations:
    required: true

# ...

Warning: It's essential to set the correct ID in issue-form

Let's define a policy that will allow us to map animals to their types. Policy needs to be stored in .github/advanced-issue-labeler.yml.

policy:
  - section:
      - id: [animals]
        block-list: ['None', 'Other']
        label:
          - name: 'kind: amphibians'
            keys: ['🐸 Frog']
          - name: 'kind: birds'
            keys: ['🐓 Rooster', '🐦 Bird', '🐧 Penguin']
          - name: 'kind: fish'
            keys: ['🐡 Blowfish', '🐟 Fish', '🦈 Shark']
          - name: 'kind: mammals'
            keys: ['🦍 Gorilla', '🐶 Dog', '🐬 Dolphin', '🐺 Wolf', '🦊 Fox', '🐴 Horse']
          - name: 'kind: reptiles'
            keys: ['🐊 Crocodile']
          - name: 'invertebrates'
            keys: ['🐛 Bug', '🕷️ Spider'] 

GitHub workflow that automatically marks issues with animal types labels:

name: Issue labeler
on:
  issues:
    types: [ opened ]

jobs:
  label-component:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Parse issue form
        uses: stefanbuck/github-issue-parser@v3
        id: issue-parser
        with:
          template-path: .github/ISSUE_TEMPLATE/bug.yml

      - name: Set labels based on animals field
        uses: redhat-plumbers-in-action/advanced-issue-labeler@v2
        with:
          issue-form: ${{ steps.issue-parser.outputs.jsonString }}
          token: ${{ secrets.GITHUB_TOKEN }}

• systemd/systemd

• blueedgetechno/win11React

• microsoft/mu_basecore

• microsoft/mu_plus

• systemd/systemd-stable

• more examples - here

Feel free to try advanced-issue-labeler in template repository - @redhat-plumbers-in-action/issue-forms-automation

Action currently accepts the following options:

# ...

- uses: redhat-plumbers-in-action/advanced-issue-labeler@v2
  with:
    issue-form: <issue-form.json>
    template:   <template-name.yml>
    section:    <section-id>
    block-list: <block-list>
    token:      <GitHub token>

# ...

Issue-form parsed into JSON file. Supported format is generated using @stefanbuck/github-issue-parser GitHub action.

• default value: undefined
• requirements: required

Each issue form can have a defined different labeling policy, and this option is used to specify which policy should be used.

• default value: undefined
• requirements: optional

The ID of the dropdown section from the issue form template.

• default value: undefined
• requirements: required

List of forbidden labels. These labels won't be set.

• default value: undefined
• requirements: optional

Note: Please notice the | in the example above ☝️. That lets you effectively declare a multi-line YAML string. You can learn more about multi-line YAML syntax here. This syntax is required when block-listing multiple labels.

Token used to set labels

• default value: undefined
• requirements: required
• recomended value: secrets.GITHUB_TOKEN

It's possible to define a labeling policy to further customize the labeling process. The policy can be defined using .github/advanced-issue-labeler.yml configuration file. The structure needs to be as follows:

policy:
  - template: ['bug.yml', 'feature.yml']
    section:
      - id: ['severity', 'priority']
        block-list: []
        label:
          - name: 'Low'
            keys: ['Low', 'None']
          - name: 'Medium'
            keys: ['Medium']
          - name: 'High'
            keys: ['High']
          - name: 'Urgent'
            keys: ['Urgent']
      - id: [animals]
        block-list: ['None', 'Other']
        label:
          - name: 'amphibians'
            keys: ['🐸 Frog']
          - name: 'birds'
            keys: ['🐓 Rooster', '🐦 Bird', '🐧 Penguin']
          - name: 'fish'
            keys: ['🐡 Blowfish', '🐟 Fish', '🦈 Shark']
          - name: 'mammals'
            keys: ['🦍 Gorilla', '🐶 Dog', '🐬 Dolphin', '🐺 Wolf', '🦊 Fox', '🐴 Horse']
          - name: 'reptiles'
            keys: ['🐊 Crocodile']
          - name: 'invertebrates'
            keys: ['🐛 Bug', '🕷️ Spider']
# - template: ...

Array of issue-forms (e.g. ['bug-report.yml']). This section is used to determine the correct labeling policy when multiple policies are defined. Works in cooperation with template option.

• requirements: optional

Equivalent of section option. An array of IDs of dropdowns. These IDs need to point to dropdowns in the issue-form template.

• requirements: required

Equivalent of block-list option. An array of forbidden keywords. These keywords will be excluded when applying labeling policy.

• requirements: required

Section of policy describing labeling policy. label section of the policy is expected to have the following properties:

• name - Name of label

• keys - Array of keywords corresponding to values from issue-form dropdown

• requirements: required

• Currently it's not possible to use strings containing ,␣ in the dropdown menu. This pattern is used in the separation process when the dropdown option multiple is set to true.