release-drafter/release-drafter

Drafts your next release notes as pull requests are merged into master.

Drafts your next release notes as pull requests are merged into master. Built with Probot.

---

Usage

You can use the Release Drafter GitHub Action in a GitHub Actions Workflow by configuring a YAML-based workflow file, e.g. .github/workflows/release-drafter.yml, with the following:

name: Release Drafter

on:
  push:
    # branches to consider in the event; optional, defaults to all
    branches:
      - master
  # pull_request event is required only for autolabeler
  pull_request:
    # Only following types are handled by the action, but one can default to all as well
    types: [opened, reopened, synchronize]
  # pull_request_target event is required for autolabeler to support PRs from forks
  # pull_request_target:
  #   types: [opened, reopened, synchronize]

permissions:
  contents: read

jobs:
  update_release_draft:
    permissions:
      # write permission is required to create a github release
      contents: write
      # write permission is required for autolabeler
      # otherwise, read permission is required at least
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      # (Optional) GitHub Enterprise requires GHE_HOST variable set
      #- name: Set GHE_HOST
      #  run: |
      #    echo "GHE_HOST=${GITHUB_SERVER_URL##https:\/\/}" >> $GITHUB_ENV

      # Drafts your next Release notes as Pull Requests are merged into "master"
      - uses: release-drafter/release-drafter@v6
        # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml
        # with:
        #   config-name: my-config.yml
        #   disable-autolabeler: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If you're unable to use GitHub Actions, you can use the Release Drafter GitHub App. Please refer to the Release Drafter GitHub App documentation for more information.

Configuration

Once you’ve added Release Drafter to your repository, it must be enabled by adding a .github/release-drafter.yml configuration file to each repository. The configuration file must reside in your default branch, no other configurations will be accepted.

Example

For example, take the following .github/release-drafter.yml file in a repository:

template: |
  ## What’s Changed

  $CHANGES

As pull requests are merged, a draft release is kept up-to-date listing the changes, ready to publish when you’re ready:

The following is a more complicated configuration, which categorises the changes into headings, and automatically suggests the next version number:

name-template: 'v$RESOLVED_VERSION 🌈'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: '🚀 Features'
    labels:
      - 'feature'
      - 'enhancement'
  - title: '🐛 Bug Fixes'
    labels:
      - 'fix'
      - 'bugfix'
      - 'bug'
  - title: '🧰 Maintenance'
    label: 'chore'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
template: |
  ## Changes

  $CHANGES

Configuration Options

You can configure Release Drafter using the following key in your .github/release-drafter.yml file:

Key	Required	Description
template	Required	The template for the body of the draft release. Use template variables to insert values.
header	Optional	Will be prepended to template. Use template variables to insert values.
footer	Optional	Will be appended to template. Use template variables to insert values.
category-template	Optional	The template to use for each category. Use category template variables to insert values. Default: "## $TITLE".
name-template	Optional	The template for the name of the draft release. For example: "v$NEXT_PATCH_VERSION".
tag-template	Optional	The template for the tag of the draft release. For example: "v$NEXT_PATCH_VERSION".
tag-prefix	Optional	A known prefix used to filter release tags. For matching tags, this prefix is stripped before attempting to parse the version. Default: ""
version-template	Optional	The template to use when calculating the next version number for the release. Useful for projects that don't use semantic versioning. Default: "$MAJOR.$MINOR.$PATCH"
change-template	Optional	The template to use for each merged pull request. Use change template variables to insert values. Default: "* $TITLE (#$NUMBER) @$AUTHOR".
change-title-escapes	Optional	Characters to escape in $TITLE when inserting into change-template so that they are not interpreted as Markdown format characters. Default: ""
no-changes-template	Optional	The template to use for when there’s no changes. Default: "* No changes".
references	Optional	The references to listen for configuration updates to .github/release-drafter.yml. Refer to References to learn more about this
categories	Optional	Categorize pull requests using labels. Refer to Categorize Pull Requests to learn more about this option.
exclude-labels	Optional	Exclude pull requests using labels. Refer to Exclude Pull Requests to learn more about this option.
include-labels	Optional	Include only the specified pull requests using labels. Refer to Include Pull Requests to learn more about this option.
exclude-contributors	Optional	Exclude specific usernames from the generated $CONTRIBUTORS variable. Refer to Exclude Contributors to learn more about this option.
include-pre-releases	Optional	Include pre releases as "full" releases when drafting release notes. Default: false.
no-contributors-template	Optional	The template to use for $CONTRIBUTORS when there's no contributors to list. Default: "No contributors".
replacers	Optional	Search and replace content in the generated changelog body. Refer to Replacers to learn more about this option.
sort-by	Optional	Sort changelog by merged_at or title. Can be one of: merged_at, title. Default: merged_at.
sort-direction	Optional	Sort changelog in ascending or descending order. Can be one of: ascending, descending. Default: descending.
prerelease	Optional	Mark the draft release as pre-release. Default false.
latest	Optional	Mark the release as latest. Only works for published releases. Can be one of: true, false, legacy. Default true.
version-resolver	Optional	Adjust the $RESOLVED_VERSION variable using labels. Refer to Version Resolver to learn more about this
commitish	Optional	The release target, i.e. branch or commit it should point to. Default: the ref that release-drafter runs for, e.g. refs/heads/master if configured to run on pushes to master.
filter-by-commitish	Optional	Filter previous releases to consider only those with the target matching commitish. Default: false.
include-paths	Optional	Restrict pull requests included in the release notes to only the pull requests that modified any of the paths in this array. Supports files and directories. Default: []

Release Drafter also supports Probot Config, if you want to store your configuration files in a central repository. This allows you to share configurations between projects, and create a organization-wide configuration file by creating a repository named .github with the file .github/release-drafter.yml.

Template Variables

You can use any of the following variables in your template, header and footer:

Variable	Description
$CHANGES	The markdown list of pull requests that have been merged.
$CONTRIBUTORS	A comma separated list of contributors to this release (pull request authors, commit authors, and commit committers).
$PREVIOUS_TAG	The previous releases’s tag.
$REPOSITORY	Current Repository
$OWNER	Current Repository Owner

Category Template Variables

You can use any of the following variables in category-template:

Variable	Description
$TITLE	The category title, e.g. Features.

Next Version Variables

You can use any of the following variables in your template, header, footer, name-template and tag-template:

Variable	Description
$NEXT_PATCH_VERSION	The next patch version number. For example, if the last tag or release was v1.2.3, the value would be v1.2.4. This is the most commonly used value.
$NEXT_MINOR_VERSION	The next minor version number. For example, if the last tag or release was v1.2.3, the value would be v1.3.0.
$NEXT_MAJOR_VERSION	The next major version number. For example, if the last tag or release was v1.2.3, the value would be v2.0.0.
$RESOLVED_VERSION	The next resolved version number, based on GitHub labels. Refer to Version Resolver to learn more about this.

Version Template Variables

You can use any of the following variables in version-template to format the $NEXT_{PATCH,MINOR,MAJOR}_VERSION variables:

Variable	Description
$PATCH	The patch version number.
$MINOR	The minor version number.
$MAJOR	The major version number.
$COMPLETE	The complete version string (including any prerelease info).

Version Resolver

With the version-resolver option version number incrementing can be resolved automatically based on labels of individual pull requests. Append the following to your .github/release-drafter.yml file:

version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch

The above config controls the output of the $RESOLVED_VERSION variable.

If a pull requests is found with the label major/minor/patch, the corresponding version key will be incremented from a semantic version. The maximum out of major, minor and patch found in any of the pull requests will be used to increment the version number. If no pull requests are found with the assigned labels, the default will be assigned.

Change Template Variables

You can use any of the following variables in change-template:

Variable	Description
$NUMBER	The number of the pull request, e.g. 42.
$TITLE	The title of the pull request, e.g. Add alien technology. Any characters excluding @ and # matching change-title-escapes will be prepended with a backslash so that they will appear verbatim instead of being interpreted as markdown format characters. @s and #s if present in change-title-escapes will be appended with an HTML comment so that they don't become mentions.
$AUTHOR	The pull request author’s username, e.g. gracehopper.
$BODY	The body of the pull request e.g. Fixed spelling mistake.
$URL	The URL of the pull request e.g. https://github.com/octocat/repo/pull/42.
$BASE_REF_NAME	The base name of of the base Ref associated with the pull request e.g. master.
$HEAD_REF_NAME	The head name of the head Ref associated with the pull request e.g. my-bug-fix.

References

Note: This is only revelant for GitHub app users as references is ignored when running as GitHub action due to GitHub workflows more powerful on conditions

References takes an list and accepts strings and regex. If none are specified, we default to the repository’s default branch usually master.

references:
  - master
  - v.+

Currently matching against any ref/heads/ and ref/tags/ references behind the scene

Categorize Pull Requests

With the categories option you can categorize pull requests in release notes using labels. For example, append the following to your .github/release-drafter.yml file:

categories:
  - title: '🚀 Features'
    label: 'feature'
  - title: '🐛 Bug Fixes'
    labels:
      - 'fix'
      - 'bugfix'
      - 'bug'

Pull requests with the label "feature" or "fix" will now be grouped together:

Adding such labels to your PRs can be automated by using the embedded Autolabeler functionality (see below), PR Labeler or Probot Auto Labeler.

Optionally you can add a collapse-after entry to your category item, if the category has more than the defined collapse-after pull requests then it will show all pull requests collapsed for that category. Append the collapse-after integer to your category as following:

categories:
  - title: '⬆️ Dependencies'
    collapse-after: 3
    labels:
      - 'dependencies'

Exclude Pull Requests

With the exclude-labels option you can exclude pull requests from the release notes using labels. For example, append the following to your .github/release-drafter.yml file:

exclude-labels:
  - 'skip-changelog'

Pull requests with the label "skip-changelog" will now be excluded from the release draft.

Include Pull Requests

With the include-labels option you can specify pull requests from the release notes using labels. Only pull requests that have the configured labels will be included in the pull request. For example, append the following to your .github/release-drafter.yml file:

include-labels:
  - 'app-foo'

Pull requests with the label "app-foo" will be the only pull requests included in the release draft.

Exclude Contributors

By default, the $CONTRIBUTORS variable will contain the names or usernames of all the contributors of a release. The exclude-contributors option allows you to remove certain usernames from that list. This can be useful if don't wish to include yourself, to better highlight only the third-party contributions.

exclude-contributors:
  - 'myusername'

Replacers

You can search and replace content in the generated changelog body, using regular expressions, with the replacers option. Each replacer is applied in order.

replacers:
  - search: '/CVE-(\d{4})-(\d+)/g'
    replace: 'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-$1-$2'
  - search: 'myname'
    replace: 'My Name'

Autolabeler

You can add automatically a label into a pull request, with the autolabeler option. Available matchers are files (glob), branch (regex), title (regex) and body (regex). Matchers are evaluated independently; the label will be set if at least one of the matchers meets the criteria.

autolabeler:
  - label: 'chore'
    files:
      - '*.md'
    branch:
      - '/docs{0,1}\/.+/'
  - label: 'bug'
    branch:
      - '/fix\/.+/'
    title:
      - '/fix/i'
  - label: 'enhancement'
    branch:
      - '/feature\/.+/'
    body:
      - '/JIRA-[0-9]{1,4}/'

Prerelease increment

When creating prerelease (prerelease: true), you can add a prerelease identifier to increment the prerelease version number, with the prerelease-identifier option. It accept any string, but it's recommended to use Semantic Versioning prerelease identifiers (alpha, beta, rc, etc).

Using prerelease-identifier automatically enable include-prereleases.

prerelease-identifier: 'alpha' # will create a prerelease with version number x.x.x-alpha.x

Projects that don't use Semantic Versioning

If your project doesn't follow Semantic Versioning you can still use Release Drafter, but you may want to set the version-template option to customize how the $NEXT_{PATCH,MINOR,MAJOR}_VERSION environment variables are generated.

For example, if your project doesn't use patch version numbers, you can set version-template to $MAJOR.$MINOR. If the current release is version 1.0, then $NEXT_MINOR_VERSION will be 1.1.

Action Inputs

The Release Drafter GitHub Action accepts a number of optional inputs directly in your workflow configuration. These will typically override default behavior specified in your release-drafter.yml config.

Input	Description
config-name	If your workflow requires multiple release-drafter configs it be helpful to override the config-name. The config should still be located inside .github as that's where we are looking for config files.
name	The name that will be used in the GitHub release that's created or updated. This will override any name-template specified in your release-drafter.yml if defined.
tag	The tag name to be associated with the GitHub release that's created or updated. This will override any tag-template specified in your release-drafter.yml if defined.
version	The version to be associated with the GitHub release that's created or updated. This will override any version calculated by the release-drafter.
publish	A boolean indicating whether the release being created or updated should be immediately published. This may be useful if the output of a previous workflow step determines that a new version of your project has been (or will be) released, as with salsify/action-detect-and-tag-new-version.
prerelease	A boolean indicating whether the release being created or updated is a prerelease.
prerelease-identifier	A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. number
latest	A string indicating whether the release being created or updated should be marked as latest.
commitish	A string specifying the target branch for the release being created.
header	A string that would be added before the template body.
footer	A string that would be added after the template body.

Action Outputs

The Release Drafter GitHub Action sets a couple of outputs which can be used as inputs to other Actions in the workflow (example).

Output	Description
id	The ID of the release that was created or updated.
name	The name of this release.
tag_name	The name of the tag associated with this release.
body	The body of the drafted release, useful if it needs to be included in files.
html_url	The URL users can navigate to in order to view the release. i.e. https://github.com/octocat/Hello-World/releases/v1.0.0.
upload_url	The URL for uploading assets to the release, which could be used by GitHub Actions for additional uses, for example the @actions/upload-release-asset GitHub Action.

Developing

If you have Node v10+ installed locally, you can run the tests, and a local app, using the following commands:

# Install dependencies
yarn install

# Run the tests
yarn test

# Run the app locally
yarn test:watch

Once you've started the app, visit localhost:3000 and you'll get step-by-step instructions for installing it in your GitHub account so you can start pushing commits and testing it locally.

If you don’t have Node installed, you can use Docker Compose:

# Run the tests
docker compose run --rm app

Contributing

Third-party contributions are welcome! 🙏🏼 See CONTRIBUTING.md for step-by-step instructions.

If you need help or have a question, let me know via a GitHub issue.

Deployment

If you want to deploy your own copy of Release Drafter, follow the Probot Deployment Guide.

Releasing

Run the following command:

git checkout master && git pull && npm version [major | minor | patch]

The command does the following:

• Ensures you’re on master and don’t have local, un-commited changes
• Bumps the version number in package.json based on major, minor or patch
• Runs the postversion npm script in package.json, which:
  • Runs test
  • Pushes the tag to GitHub, which triggers GitHub Action that does the following:
    • Push GitHub app to Heroku
    • Releases NPM
    • Publish the Release Draft!

release-drafter's Issues

untagged-<HASH> being set as Tag name

New drafts have their tag name being set as untagged-

Our version tags are set as v1.1.1-staging and v1.1.1-production.

Looking through the code I can see that the semver package is used to parse the version out of the lastRelease's tag name. This seems to work fine when I test locally.

Here are my relevant settings

# release-drafter.yml
name-template: "v$NEXT_PATCH_VERSION"
tag-template: "v$NEXT_PATCH_VERSION-staging"

My thought is perhaps the NEXT_PATCH_VERSION variable is causing an error when I append the -staging to it. If this is the case, how do I properly separate the two.

Wildcard Branches

on https://github.com/jenkinsci/blueocean-plugin we use master for the next release (its 1.x.0) and releases/vfoo for 1.foo.1 type patches)

The branches mentioned in the readme, digging through the code it doesn't seem like they support wildcards. Do they? do you want a patch to do so?

PRs that only have the repository as a source are shown in changelogs

Our changelog shows PRs from our repo into a fork. This is especially annoying since https://github.com/apps/pull is used to keep the forks up to date which creates a lot of those PRs. The link to those PRs is also wrong, since it uses the right id but the wrong repo.

So in bakdata/conquery you can see

while these PRs are actually in a fork, e.g.

Autocategorize by label?

Hey, did you think about taking this bot a step forward in the future and make it configurable that the drafter only lists merged PR with specific label, and even that you can have different sections in a template and Pr with specific label in the section?

Support label prefixes

Problem

#85 added very useful feature to categorize according to labels. But when you have nested labels you might want to group them together for example (slightly contrived example):

ui/bug, ui/new-feature, ui/something and one might want to group all the labels that start with a ui/ prefix together under one category. (This labeling scheme is very common, especially in OSS projects)
To my understanding, today, the label is matched in its entirety, as is.

Proposed Solution

Match labels based on prefix (which would also cover the basic case of full matching)

Categorize based on PR labels

Hey there, great little bot 👍

I saw that in #35 autocategorization was implemented by using "labels" but this is just looking into the title the PR, not the actually assigned GitHub labels (like the default labels bug and improvement)
Is my assumption correct? No.

Sorry I thought I tested this in a dummy repo, but somehow I messed it up.
It actually already works the way I want it to.

Squash & Merge PRs

I always use squash & merge when merging PRs. Just realized that this doesn't work with release-drafter. My change log looks like this:

Looking at the code, merge PRs are matched on "Merge pull request #" https://github.com/toolmantim/release-drafter/blob/e24d69800ca69614e821cf642097dd82e5206cd3/lib/commits.js#L23

Could this be updated to also match commits generated by squash & merge?

For example, (\(#\d+\))$|Merge pull request #\d+ (link):

Support non-semver releases

Currently if you try to use Release Drafter on a repo that has non-semver compatible release names, it throws Error: Invalid argument not valid semver when compare-versions is used.

We should perhaps just compare the dates of the two releases in this case, and assume the more recent release is greater?

Draft with old PRs in it

I've got a draft hanging out on my releases page with all the old PRs up to and including the one that configured Release Drafter; anything that came after that isn't getting drafted. What can I do to get release drafter to ignore/consider those closed/drafted and move on? We were manually making releases before this.

Bot users don’t render quite right

It seems that bot users are inlined as usual, and count as contributors, which results in a bit of unusual rendering:

• 7: Update dependency emoji-regex to v7.0.1 by @renovate[bot]

Thanks to @renovate-bot, @renovate[bot] and @ticky!

Support for rebase merging

Currently rebase merging is not supported because Release Drafter checks for merge commits which don't exist when using rebase merging. At our company we're unable to use Release Drafter because we use rebase merging. Adding support for rebase merging requires a bit of a rewrite since it shouldn't rely on commits anymore, instead we can use the search endpoint (or search field in the GraphQL API) to fetch pull requests.

Here's an example query:

{
  search(type: ISSUE, query: "type:pr merged:>=2018-11-10 repo:toolmantim/release-drafter", first: 10) {
    nodes {
      ... on PullRequest {
        title
        number
        author {
          login
        }
        mergedAt
      }
    }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

Would you be interested in this @toolmantim? I could start working on it tomorrow and next week :)

Installing works on GitHub Enterprise - almost

Having followed the installations instructions, i.e. Remember to set GHE-HOST, and install via http://localhost:3000 I have succesfully(?) installed release-drafter into our GitHub Enterprise (version: 2.16.5) instance.
I have installed the GitHub App on an test organisation and activated it in a test repository.
Having a very basic configuration of release-drafter.yml in the .github folder of the repository, there is absolutely no activity in regards to creating a release draft.
The application itself is triggered, since there is communication with https://smee.io.

A request:

And the corresponding response:

The release-drafter config for the organization is set as such:

The release-drafter application config is set as such:

Please advise on what further to do, so I can get this working.

We are behind a corporate proxy, but I do not think this is the issue, since there is a Response Code 200 from https://smee.io

non-semver next version?

Would you be interested in supporting non-semver next version?

I know it is not much to change the name but selecting the right tag can be a little cumbersome.

Would love to contribute the work, if you'd be interested.

Excess Old Pulls & Issues

Config

https://github.com/theme-next/hexo-theme-next/blob/master/.github/release-drafter.yml

# Configuration for Release Drafter - https://github.com/toolmantim/release-drafter

name-template: 'v$NEXT_MINOR_VERSION'
tag-template: 'v$NEXT_MINOR_VERSION'
categories:
  - title: '💥 Breaking Changes'
    label: '💥 Breaking Change'

  - title: '🌀 External Changes'
    label: '🌀 External Change'

  - title: '🌟 New Features'
    label: '🌟 New Feature'

  - title: '⭐ Features'
    label: '⭐ Feature'

  - title: '🛠 Improvements'
    label: '🛠 Improvement'

  - title: '🐞 Bug Fixes'
    label: '🐞 Bug Fix'

  - title: '📖 Documentation'
    label: '📖 Docs'

  - title: '🌍 Localization'
    label: '🌍 i18n'

change-template: '- $TITLE (#$NUMBER)'
no-changes-template: '- No changes'
template: |
  $CHANGES
  ***
  For full changes, see the [comparison between $PREVIOUS_TAG and v$NEXT_MINOR_VERSION](https://github.com/theme-next/hexo-theme-next/compare/$PREVIOUS_TAG...v$NEXT_MINOR_VERSION)

Problem

Issue #25 and Pull #22 was closed in 2018. As we can see, at least pulls under ≈800x numbers can be included, not ≈100x.

Possible solution

In previous month that bug wasn't appear as I remember. Also, emoji on labels wasn't used before, maybe some conflict here.

Buildkite is not allowed by Travis

I had a slightly unexpected event after I created #92 - my Travis account was suspended due to the content of .travis.yml in my fork. Apparently the code you have to download a buildkite agent is disallowed on Travis.

After some discussion @luna-travisci kindly unsuspended my Travis account. However, I thought I should flag this to you, firstly to avoid a potential landmine for future contributors, and secondly because I'd imagine this also means that your Travis builds are offline as well.

Generated draft does not list changes

I have a PR merged, draft is indeed generated, but it does not list that PR. Actually it says "no changes".
May be related to #29, but it happens to me today.

Unfortunately my repository is private.
May be it's possible to check the logs.
On the image there might be useful info to search the logs for, like PR number, commit etc
Thanks in advance.

Display Pull Request Description with Title

We would like to include our pull request descriptions to be displayed along side the titles for our releases if possible.

Is it possible to add a configuration option for this?

Executing the Dockerfile shows Usage and then exits

When executing the Dockerfile I get this out:

Usage: probot-receive [options] [path/to/app.js...]

Options:
  -e, --event <event-name>           Event name
  -p, --payload-path <payload-path>  Path to the event payload
  -t, --token <access-token>         Access token
  -a, --app <id>                     ID of the GitHub App
  -P, --private-key <file>           Path to certificate of the GitHub App
  -h, --help                         output usage information

My slightly customized Dockerfile:

FROM node:10.16.0-alpine@sha256:07897ec27318d8e43cfc6b1762e7a28ed01479ba4927aca0cdff53c1de9ea6fd
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}
ENV http_proxy=http://[PROXY SERVER ADDRESS]:8080 \
 https_proxy=http://[PROXY SERVER ADDRESS]:8080 \
 no_proxy=[LOCAL DOMAIN] \
 NODE_TLS_REJECT_UNAUTHORIZED=0

ENV APP_ID=[APP ID]
ENV WEBHOOK_SECRET=[WEBHOOK SECRET]
ENV GHE_HOST=[GITHUB ENTERPRISE EDITION]
ENV LOG_LEVEL=trace
ENV PORT=8080
ENV PRIVATE_KEY="[RSA PRIVATE KEY]"

LABEL "repository"="https://github.com/toolmantim/release-drafter"
LABEL "homepage"="https://github.com/toolmantim/release-drafter"
LABEL "maintainer"="Tim Lucas"
LABEL "com.github.actions.name"="Release Drafter"
LABEL "com.github.actions.description"="Drafts your next release notes as pull requests are merged into master."
LABEL "com.github.actions.icon"="edit-2"
LABEL "com.github.actions.color"="orange"
WORKDIR /app
COPY . .
RUN yarn config set strict-ssl false
RUN yarn --frozen-lockfile
ENTRYPOINT [ "/app/node_modules/.bin/probot", "receive", "/app/index.js" ]

What am I missing?

Allow custom user templating?

Would be nice to give the user some templating power.

For instance, I need a regex capturing of JENKINS-\d+ like JENKINS-123 and turn it into a Markdown link of [JENKINS-123](https://issues.jenkins-ci.org/browse/JENKINS-123) JENKINS-123

Would be possible to add once #161 is merged.

The user templating would be run last.

GitHub Action doesn't trigger on tag push

Pushing tags doesn't trigger a new draft release when a new tag goes out, as it thinks it's a branch and ignores it ( https://github.com/toolmantim/release-drafter/runs/113476390). It should always run for tag pushes, and only filter branches for code pushes to refs/head*

Add commits to release draft

Hi @toolmantim, thanks for this great app!

It would be nice to be able to add commits to the triggerable branch to the release as well. This would be especially helpful for small or young projects.

For example a boolean property track-commits could be added to the config to enable the functionality. Then the message according to change-template is created with $TITLE set to the commit title and $NUMBER set to the commit hash.

I might be able to work on this on my own if I find time for it. Just want to find out if this is desired.

Release Drafter is not creating the next release (and updating it)

Not sure if I did something wrong but after I have released a new version (2.6) of my project, Release Drafter does not seem to create a draft for the next release (2.7) although I'm merging PRs.

May be my configuration file is incorrect? Is there any way to have some logs?

name-template: v$NEXT_PATCH_VERSION 🌈
tag-template: v$NEXT_PATCH_VERSION
categories:
  - title: 🚀 New features
    label: new
  - title: 🚨 Bug Fixes
    label: bug
  - title: 💉 Updated features
    label: update
  - title: 🧹 Cleaned or removed features
    label: remove
  - title: 📝 Documentation updates
    label: doc
  - title: 🚦 Tests
    label: test
change-template: - #$NUMBER: $TITLE (thanks to @$AUTHOR)
template: |
  ## What's Changed

  $CHANGES

  ## Thanks to

  $CONTRIBUTORS

My project lives at: https://github.com/dadoonet/fscrawler
The new milestone I'm working on: https://github.com/dadoonet/fscrawler/milestone/24?closed=1

Here is what I can see in the releases section:

One contributor have "and" in $CONTRIBUTORS

$CONTRIBUTORS variable have "and @contributor" when contributor is only one.

A comma separated list of contributors to this release (pull request authors, commit authors, and commit committers).

Automatically name new draft releases according to semver

Firstly thanks for creating this - I've used it in a couple of places and found it very helpful!

I'm wondering if you would accept a contribution for an opt-in feature to automatically name new draft releases. What I would like is for each new release to be Last Release + 0.0.1. My goal is to make it really easy to make a new patch release (as our most common release type), so that 'working out the next patch version number' becomes a mental no-op, as performing the release can be just a case of hitting the publish button.

Obviously there will be times when it's more appropriate to increment the major or minor version, but this would be easily done manually with no additional mental overhead from now.

How does this sound as a potential new feature?

Release Target Setting

Would be really helpful if the Release Draft Target (optionally) was the latest commitish.

The two issues with using Master as the Target are:

1. PR merged to master in the time that someone is viewing the draft, the merged PR will not be documented on the release.
2. If the release is modified to link to another tag, the tag will actually mark the current state of master. So a release candidate, beta, or staging process has the potential to break.

It is a fairly easy thing to automate (https://developer.github.com/v3/repos/releases/#create-a-release)

If this gets a 👍 I can write and submit this PR myself!

Categories: Add support of multiple labels per category

I am working on a global Release Drafter configuration in https://github.com/jenkinsci . The organization contains numerous repositories which use different tags due to historical reasons. I am interested to streamline labeling in our repositories, but it will take a while.

For example, this is a configuration for bugfix tags:

categories:
  - title: 🐛 Bug Fixes
    label: bug
  - title: 🐛 Bug Fixes
    label: fix
  - title: 🐛 Bug Fixes
    label: bugfix
  - title: 🐛 Bug Fixes
    label: regression  

From a UX perspective, it would be great to have support of multiple labels definition, e.g.

categories:
  - title: 🐛 Bug Fixes
    labels: 
      - bug
      - fix
      - bugfix
      - regression  

Open PRs on new repos with default config

I just enabled Release Drafter on a couple of repos and thought it was broken for a while before remembering that it requires also adding a template. It would be great if when adding access to a new repo that doesn't have a template that a PR would be opened adding the default template.

This is something that Renovate does and it's fantastic. abraham/remotedata#1

Auto-publish release feature

Since #91 we've been able to get many of our repos using release drafter, with a nice Releases page and automatic patch version bumps. Thanks again for this tool!

One additional feature that we'd be really interested in contributing is automatic publication of releases. For many of our repos we typically want to release a new version after each PR is merged.

I thought of creating a separate probot to do this in the spirit of separation of concerns. However there is no hook for 'draft release created'; Release Drafter, as the creator of the draft release, is really in a unique position of being able to do this.

So I'd like to propose adding a feature that would:

• be opt-in via a new config flag
• require a template for release tag and name
• automatically publish a release after it has been created
• ... if/unless some configurable label is present on the just-merged PR

I'd be keen to get your thoughts on this!

Diff to prevent clobbering?

Apologies if this has already been asked/answered.

We're exploring using Github releases to track moves to production at our company, and one thing we do now before pushing to prod is run through a manual check list that an employee "signs" before we deploy a release.

I was thinking it'd be nice for this checklist to be in the release-drafter.yml file, but of course the issue is that if any more PRs are merged before a push (perhaps one of the check list items clues us into a last minute change that needs to be merged) then any changes to the checklist (i.e. changing [ ] to [x] or adding comments) will be overwritten when Release Drafter regenerates the draft description.

Is there any option for preventing this clobbering from happening, or leaving a part of the template that doesn't get clobbered upon regeneration?

Attribute changes to the original author

Hi,

Great tool!
I tested it on one of my repo:

Would it be possible to attribute the changes to the original author instead of the person who merged the PR?

Thanks

How to configure this with gitflow?

I tried, really. But I didn't find a way to create the release.

Our repo has base branch set to develop, but I only want to create releases for code ending up on master.

Relevant Release Drafter config: https://github.com/inthepocket/hubble-scripts/blob/develop/.github/release-drafter.yml

Tried first with merging remotes into master and pushing, then tried to merge via PR from develop to master, but the release is not showing up as a Draft when I go to the releases tab.

Support for changing sorting direction

There's currently a small bug where the first draft with no prior releases will be sorted in reverse-chronological order but if the repo already has one or more prior releases it will be sorted in chronological order. I assume this happens because there's a difference in sorting order with compareCommits and listCommits (https://github.com/toolmantim/release-drafter/blob/master/lib/commits.js#L4). After #164 is merged, PRs will always be sorted in reverse-chronological order. I think it makes sense to add a sort-direction option that accepts either chronological or reverse-chronological so that users can decide for themselves what they like best.

May I use this tool for my local repository?

My projects are not on Github. They are in internal company because of policy. I feel this is great tool, but if it could install locally will be better.

Add support of generating machine-readable changelogs (YAML?)

As a maintainer, I would be interested to generate a machine-readable changelog in addition to user release notes.

Currently Release Drafter targets Markdown as a destination format. In the case of the Jenkins project, we maintain a machine readable changelog in YAML so that we can later generate https://jenkins.io/changelog/ and other data sources. Raw data: https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml

Currently the changelog is generated using automation scripts, but it would be great to use Release Drafter.

What would I expect from YAML generation:

• Being able to use replacer-alike approach to extract data from the message and to inject YAML fields
• Simplified generation of the YAML output syntax

Workaround

I was able to hack a workaround using non-trivial replacers to extract issue numbers and to put them into YAML.

Configuration:

# Configuration for Release Drafter: https://github.com/toolmantim/release-drafter
name-template: $NEXT_PATCH_VERSION
# Uses a more common 2-digit versioning in Jenkins weekly releases.
version-template: $MAJOR.$MINOR
tag-template: jenkins-$NEXT_MINOR_VERSION

# TODO: categories are YAGNI for now, until we can extract `type` somehow
exclude-labels:
  - reverted
  - no-changelog
  - skip-changelog
  - invalid
change-template: |-
  - type: todo
    message: |-
      $TITLE
    pull: $NUMBER
    authors:
      - $AUTHOR
template: |
  '''yaml
  $CHANGES
  '''
replacers:
  - search: '/\[*JENKINS-(\d+)\]*\s*-*\s*/g'
    replace: |-
      issue: $1
        message: |-
          
  - search: |-
      message: |-
          issue:
    replace: "issue:"

Generated output:

Duplicated/Incorrect PRs listed

Hi,

I am getting some random very old PRs linked, or incorrect IDs or something strange.

As you can see below "Fixture Upgrade" is duplicated and the 2nd one links to a random old PR.

Project is OSS: here is the config: https://github.com/gerbera/gerbera/blob/master/.github/release-drafter.yml

Please help!

---

Add $CATEGORIES as a template variable

Currently the categories will just be appended to the end of the template. I would like to control where in the template they go. So if we had a $CATEGORIES variable that could go in the template string that would solve the problem.

An example

name-template: v$NEXT_PATCH_VERSION
tag-template: v$NEXT_PATCH_VERSION
categories:
  - title: Bug Fixes
    label: fix
change-template: '- $TITLE (#$NUMBER) @$AUTHOR'
template: |
  $CATEGORIES

  ## Other Changes

  $CHANGES

would result in this:

## Bug Fixes

- fix: example (#2) @smyrick

## Other Changes

- docs: other change (#3) @smyrick

Reduce the required GitHub permissions

Hey,

Just went to add this to an org-level repo. Noticed that it required the 'write code' permission. That's a little daunting.

Is there a list of reasons behind the permissions required?

Add support for the .github repository

Hi there,

Thanks for making this fantastic tool, definitely much appreciated.

So one feature that github added recently was a global .github repository which would allow templates for your entire organization https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/

One thing that would be great since our github organisation with 8 different active projects is to have only one 'release-drafter.yml' file using that repository.

Maybe it'd be possible to look up to see if that file exists in that .github repository and use that if one doesn't exist in the current repository?

Empty value for parameter `id`: undefined

I'm experiencing the follow issue:

11:05:22.661Z DEBUG github: GitHub request: GET /repos/:owner/:repo/compare/:base...:head - 200 OK (id=191aa04e-a07b-11e8-848e-10235e0ffbd8, installation=152769)
  params: {
    "owner": "frenck",
    "repo": "addon-example",
    "base": "v10.32.6",
    "head": "master",
    "baseUrl": "https://api.github.com",
    "request": {
      "timeout": 0
    }
  }
11:05:22.662Z  INFO probot: frenck/frenck: Found pull request numbers: 6
11:05:23.620Z DEBUG github: GitHub request: GET /repos/:owner/:repo/pulls/:number - 200 OK (id=191aa04e-a07b-11e8-848e-10235e0ffbd8, installation=152769)
  params: {
    "owner": "frenck",
    "repo": "addon-example",
    "number": 6,
    "baseUrl": "https://api.github.com",
    "request": {
      "timeout": 0
    }
  }
11:05:23.620Z  INFO probot: frenck/frenck: Updating existing draft release
11:05:23.620Z ERROR event: Empty value for parameter 'id': undefined (id=191aa04e-a07b-11e8-848e-10235e0ffbd8)
  HttpError: Empty value for parameter 'id': undefined
      at Object.keys.forEach.parameterName (/Volumes/CODE/hassio-addons/probot-addons-assistant/node_modules/probot/node_modules/@octokit/rest/lib/plugins/endpoint-methods/validate.js:27:13)
      at Array.forEach (<anonymous>)
      at validate (/Volumes/CODE/hassio-addons/probot-addons-assistant/node_modules/probot/node_modules/@octokit/rest/lib/plugins/endpoint-methods/validate.js:9:31)
      at process._tickCallback (internal/process/next_tick.js:68:7)
  --
  event: {
    "id": "191aa04e-a07b-11e8-848e-10235e0ffbd8",
    "event": "push",
    "repository": "frenck/addon-example",
    "installation": 152769
  }

The draft was created, but empty:

Any idea?

Incorrect timestamp is used when drafting

@TimonVS seems that the GraphQL is using the date from the tag/release when it was created instead of using the date from when the tagged commit was created. That way, not all PRs will show 😢

https://github.com/jenkinsci/accurev-plugin

Environment variable for all contributors

Thanks for this awesome app! We just installed it and are going to start using it on the @probot org.

It'd be cool if the template included a string of all the people who contributed changes for a release so we could give them a special shoutout. I'm imagining adding this to our template:

Special thanks to everyone who contributed to this release: $CONTRIBUTORS

Incorrect author attributed

Example shows our org (@home_assistant) getting the attribution:

---

But the commits are by real people:

Support commit message description

Add support for including the commit message's description

I specifically created casz/no-merge-description-extension
to avoid GitHub's default behavior when merging pull requests.

Would be useful in cases like this jenkinsci/configuration-as-code-plugin@850bfa4

The description could be inside <!-- --> as an aide to the release author.

CLI Tool?

Would be great to have as a CLI tool so you could move your changelog to GitHub prior to using release-drafter 🌈

Parsing the commit history between versions and producing drafts on GitHub that we than could choose to modify/release 🙌

Consider adding closed issues to release

A section where all the issues that were closed after the last release are added.

Allow wildcard or regexp branch names in the config file

Problem

• repo's default branch is development
• repo's stable branch is master
• dev team bases off of development, works on a few features, bug fixes, etc
• team is ready to draft a release, so they open a new branch called release/v1.0.10, where the v1.0.10 corresponds to the version of software they intend to release
• release drafter config file can't pick up the comparison and create the draft, as it only parses strings

Proposed Solution

• make changes to the triggerable-branch script to read wildcards / regular expressions instead of just strings

@toolmantim looking at the triggerable-branch script, I think that's where the solution needs to be implemented, but if there's any suggestions you may have or quirks I need to be aware of, let me know! If you're cool with this feature addition, I can get cracking on it asap.

Release Author

It looks like in your latest releases, the author is attributed to you.

Previously, it was either release-drafter and more recently github-actions:

I've switched from the bot to using github-actions thinking this would help fix the author, but I'm showing github-actions still. How did you get the draft to publish under your name?

This is required due to my CI having authorization for building releases for tags based on the author of the tag (which was previously the bot and would fail).

Thanks in advance!

associatedPullRequests and graphql with local deployment

I was trying to deploy this locally but I keep running in to this schema problem. I think it's because it's missing "@octokit/graphql-schema" but I'm not too sure. I think I installed the module but it's still getting the same error. Have you guys seen this with a local deployment?

02:57:01.336Z ERROR event: Field 'associatedPullRequests' doesn't exist on type 'Commit' (id=ea30ddf8-8d86-11e9-959c-37e2eb14684d)
GraphqlError: Field 'associatedPullRequests' doesn't exist on type 'Commit'
at request.then.response (/app/node_modules/@octokit/graphql/lib/graphql.js:31:15)

Release not being updated

https://github.com/home-assistant/home-assistant-polymer/releases

Our release hasn't been updated in 2 days but PRs have been merged. By any chance any issues in the release drafter logs?

And here are the commits:

Automatic name draft releases according to labels

I follow semver and I would like to have release drafter draft releases accordingly.
If features are added $MAJOR.$MINOR.$PATCH only the minor should be bumped.

Is there a way to automate the version name to such an extent?

Kind regards,
Remzi