Add $CATEGORIES as a template variable

[smyrick]

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

[TimonVS]

This feature makes a lot of sense to me. We should probably keep $CHANGES like it is to not break people's workflows.

We could decide to introduce two new variables: $CATEGORIZED_CHANGES and $UNCATEGORIZED_CHANGES, or we could change the way $CHANGES is rendered to always append uncategorized changes at the end with the ## Other Changes header.

[toolmantim]

It'd be really nice if we could switch to this:

categories:
  - title: 🚀 Features
    label: feature
  - title: 🐛 Bug Fixes
    label: fix
template: |
  $CHANGES

producing:

## 🚀 Features

* Add important feature (#2) @TimonVS 

## 🐛 Bug Fixes

* Important bug fix (#1) @TimonVS 

## Other Changes

* Update documentation (#3) @TimonVS 

and if you wanted to change the header label:

categories:
  - title: 🚀 Features
    label: feature
  - title: 🐛 Bug Fixes
    label: fix
  - title: 📝 Other Changes
template: |
  $CHANGES

(aka label: null)

That might be hard to keep backwards compatibility though @TimonVS?

[TimonVS]

Agreed @toolmantim, let's go with that :)

[jetersen]

I'd like to work on this, as an preparation I wanted to add schema to catch configuration mistakes, I feel like the configuration is becoming increasingly complex to warrant a schema.

[toolmantim]

That’d be great @jetersen. I did that for https://buildkite.com/changelog/36-autocomplete-for-your-pipeline-dot-yml-files and it was 👌🏼

We can submit it to http://schemastore.org/json/ for the file pattern release-drafter.yml and have it point to a schematic in this repo (see my PR SchemaStore/schemastore#578 for an example)

This would mean that when run as a GitHub Action (#181) we could output nicer config valuation errors too using AJV, as we did with https://github.com/buildkite-plugins/buildkite-plugin-linter

[jetersen]

Sure, I built the schema with Joi (idea taken from stale bot) I should be able to convert Joi to JSON schema 😉

[oleg-nenashev]

+1 from me. I am working on the pre-release changelog generation for Release Drafter for https://github.com/jenkinsci/jenkins. , and I would like to add categories like bug or rfe to follow https://jenkins.io/changelog/

My suggestion would be to not only follow the labels, but to actually introduce a new category ID field so that we can split the labeling and the changelog parts:

categories:
  - title: 🚀 New features and improvements
    id: rfe 
    labels:
      - enhancement
      - feature
  - title: 🐛 Bug Fixes
    id: bug
    labels:
      - bug
      - fix
      - bugfix
      - regression  

P.S: Current YAML draft is here: https://github.com/oleg-nenashev/jenkins/releases/tag/untagged-010cd0d0ed069df04d00

CC @daniel-beck

[Mike-E-angelo]

Yeahhh this is an amazing product! We are incorporating it into our repo... and the first thing that strikes you is where the features are in relation to everything else.

https://i.imgur.com/92cSUbB.gifv

😆

Having the ability to separate categories from the "remainder" would be awesome. 👍

[jetersen]

I think with my recent changes to #412 this should be fairly easy to introduce as I have split the uncategorized changes from the changes array.

[jetersen]

created #1013