Contents

• Outline
• Blog series
• Release Drafter configuration file
  • version
  • categories
  • autolabeler
  • commitish
  • Release note contents
• GitHub Actions
• Use Git tag to release Release note
• Conventional PR Title Action
• Completed

Outline

When you manage open source or versions on GitHub, you may write the Release note.

However, you can’t create the Release note by making the Pull request every time, or by creating the Release note while seeing the history of Git before the release.

In this blog post, I will introduce how to use Release Drafter of GitHub Actions to write the Release note automatically by using the Pull request title.

• Release Drafter

Blog series

This blog post is a series. You can see the other posts on the link below.

• [GitHub Actions] Check title of Pull request
• [GitHub Actions] Use Release Drafter to automate Release note of GitHub
• [GitHub Actions] Check label of Pull request
• [GitHub Actions] Automate to update Changelog file

Release Drafter configuration file

To use Release Drafter for automating Release note, the Release Drafter configuration file should be in the main(master) branch.

To make the configuration file of Release Drafter, create the .github/release-drafter.yml file and modify it like the following.

name-template: "v$RESOLVED_VERSION"
tag-template: "v$RESOLVED_VERSION"
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
categories:
  - title: '⚠️ Breaking changes'
    labels:
      - 'breaking change'
  - title: '🚀 Features'
    labels:
      - 'feature'
  - title: '🐛 Bug Fixes'
    labels:
      - 'bug'
  - title: '📃 Documents'
    labels:
      - 'docs'
  - title: '🧩 Dependency Updates'
    labels:
      - 'deps'
      - 'dependencies'
      - 'bump'
      - 'chore'
    collapse-after: 5
  - title: '🔬 Others'
    labels:
      - 'style'
      - 'refactor'
      - 'test'
      - 'ci'
    collapse-after: 5
autolabeler:
  - label: 'breaking change'
    title:
      - '/!:/i'
  - label: 'feature'
    title:
      - '/feat:/i'
  - label: 'bug'
    title:
      - '/fix:/i'
  - label: 'style'
    title:
      - '/style:/i'
  - label: 'refactor'
    title:
      - '/refactor:/i'
  - label: 'test'
    title:
      - '/test:/i'
  - label: 'chore'
    title:
      - '/chore:/i'
  - label: 'docs'
    title:
      - '/docs:/i'
  - label: 'ci'
    title:
      - '/ci:/i'
  - label: 'dependencies'
    title:
      - '/deps:/i'
      - '/dependencies:/i'
      - '/bump:/i'
commitish: main
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&'
template: |
  $CHANGES

Next, let’s see the details of Release Drafter configuration file.

version

Release Drafter basically works by using the label of Pull request. Release Drafter sees the previous Release note version and writes a new Draft of the Release note.

name-template: "v$RESOLVED_VERSION"
tag-template: "v$RESOLVED_VERSION"
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
...

At this time, the Draft should be a higher version than the previous version. Release Drafter uses the version-resolver to create the higher version of the Draft.

When the patch, minor, or major label is set to the Pull request, Release Drafter recognizes it and updates the Draft version. If no label is configured to the Pull request, the default value works. In this example, the default value is the patch, so if no label is set, the patch version is increased.

The version of the Release note is determined by the label of the last merged Pull request, rather than the version being continuously updated for each Pull request.

In this blog post, I will introduce how to use Tag in Git to determine the final version, not this version.

categories

Using the categories option, you can categorize the contents to be written in the Release note.

...
categories:
  - title: '⚠️ Breaking changes'
    labels:
      - 'breaking change'
  - title: '🚀 Features'
    labels:
      - 'feature'
  - title: '🐛 Bug Fixes'
    labels:
      - 'bug'
  - title: '📃 Documents'
    labels:
      - 'docs'
  - title: '🧩 Dependency Updates'
    labels:
      - 'deps'
      - 'dependencies'
      - 'bump'
      - 'chore'
    collapse-after: 5
  - title: '🔬 Others'
    labels:
      - 'style'
      - 'refactor'
      - 'test'
      - 'ci'
    collapse-after: 5
...

If you use the categories option like the example, you can categorize the contents of the Release note like the following.

This category is also determined by the label of Pull request. The contents, which have labels set under the labels option, are created under the title category. Also, you can use the collapse-after option to collapse contents if there is a lot of them.

autolabeler

You can categorize the contents in the Release note by the categories option, but this is determined by the label of the Pull request. So, if you forget to set the label, the content is not shown on the Release note.

To prevent this, Release Drafter provides autolabeler.

...
autolabeler:
  - label: 'breaking change'
    title:
      - '/!:/i'
  - label: 'feature'
    title:
      - '/feat:/i'
  - label: 'bug'
    title:
      - '/fix:/i'
  - label: 'style'
    title:
      - '/style:/i'
  - label: 'refactor'
    title:
      - '/refactor:/i'
  - label: 'test'
    title:
      - '/test:/i'
  - label: 'chore'
    title:
      - '/chore:/i'
  - label: 'docs'
    title:
      - '/docs:/i'
  - label: 'ci'
    title:
      - '/ci:/i'
  - label: 'dependencies'
    title:
      - '/deps:/i'
      - '/dependencies:/i'
      - '/bump:/i'
...

You can use autolabeler to set the label automatically to the Pull request by using the title, contents, file, or branch of the Pull request.

commitish

Release Drafter basically operates based on refs/heads/master. So, those how use the main branch like me should set main in commitish to tell Release Drafter that the default branch is main, not master.

...
commitish: main
...

Release note contents

These options determine the contents of the Release note. Changes are written in the form of change-template, and you can add some other contents by using the template option.

...
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&'
template: |
  $CHANGES

Also, you can add some characters to the change-title-escapes option that you want to exclude from the title of the Pull request.

GitHub Actions

Now, we’re ready to use Release Drafter. Next, let’s write the GitHub Actions to run Release Drafter.

Create the .github/workflows/release-drafter.yml file and modify it like the following.

name: Release Drafter

on:
  push:
    branches:
      - main
  pull_request:
    types:
      - opened
      - reopened
      - edited
      - synchronize

permissions:
  contents: read

jobs:
  update_release_draft:
    permissions:
      contents: write
      pull-requests: write
      checks: write
    runs-on: ubuntu-latest
    steps:
      - uses: release-drafter/[email protected]
        env:
          GITHUB_TOKEN: $

After writing the GitHub Actions like this, when the Pull request is created, you can see the label set automatically by the title of the Pull request. And when the Pull request is merged, you can see the Release note updated automatically, too.

Use Git tag to release Release note

The Release note written by Release Drafter is draft not released. You can also release the Release note by using Release Drafter.

To release the draft of the Release note, create the .github/workflows/release.yml file and modify it like the following.

name: Release

on:
  push:
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+'

jobs:
  release:
    permissions:
      contents: write
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - name: Get semantic version
        id: semver
        run: echo "::set-output name=version::${GITHUB_REF#refs/tags/v}"
      - uses: release-drafter/[email protected]
        with:
          tag: $
          name: $
          version: $
          publish: true
        env:
          GITHUB_TOKEN: $

And then, you can use Git tag like the following to use this GitHub Actions.

# git checkout main
git tag v1.0.0
git push origin v1.0.0

Conventional PR Title Action

In this blog post, we’ve used autolabeler of Release Drafter to add the label automatically by the title of the Pull request. So, when the Pull request is created, it’s better to check the title of the Pull request for it.

For this, you can use Conventional PR Title Action of GitHub Actions.

If you want to know how to use Conventional PR Title Action, please see the following link.

• [GitHub Actions] Check title of Pull request

Completed

Done! we’ve seen how to use Release Drafter of GitHub Actions to add the title of the Pull request to Release note automatically. If you manage open source or want to manage Release note well, I recommend using Release Drafter.

If the project uses the CHANGELOG.md, you can also automate adding the Release note contents to the CHANGELOG.md file by GitHub Actions. If you want to know how to update automatically the CHANGELOG.md file, please see the following link.

• [GitHub Actions] Automate to update Changelog file

Github Sponsor Buy me a coffee

Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!

App promotion

You can use the applications that are created by this blog writer Deku.
Deku created the applications with Flutter.

If you have interested, please try to download them for free.

word learning app for kids

BlaBoo

Korean TOPIK vocabulary app

TOPIK words

Japanese vocabulary app

Japanese words

Chinese HSK vocabulary app

HSK words