Extract breaking information from PR body #52

New Issue

noerw · 2021-03-12T04:38:53Z

noerw commented

2021-03-12 04:38:53 +00:00

A major purpose of changelogs is to find out about breaking changes, which should be stated as specific as possible. Currently PR title is used, which is rarely helpful.

Given 2 PRs #101: add more CLI flags & #303: fix CVE with comment bodies containing something like

adds more flags to the CLI

### breaking changes
- `tea issue create`: `-b` moved to `-d`

this fixes CVE-2021-20261

### breaking changes
- remove all teh features!

the following CHANGELOG could be generated:

### BREAKING
- `tea issue create`: `-b` moved to `-d` (#101)
- remove all teh features! (#303)

### SECURITY
- fix CVE (#303)

### ENHANCEMENT
- add more CLI flags (#101)

The tag used to extract the section could also be an HTML comment

<!-- changelog-breaking-start -->
<!-- changelog-breaking-end -->

ref gitea/tea#346

A major purpose of changelogs is to find out about breaking changes, which should be stated as specific as possible. Currently PR title is used, which is rarely helpful. Given 2 PRs `#101: add more CLI flags` & `#303: fix CVE` with comment bodies containing something like ```md adds more flags to the CLI ### breaking changes - `tea issue create`: `-b` moved to `-d` ``` ```md this fixes CVE-2021-20261 ### breaking changes - remove all teh features! ``` the following CHANGELOG could be generated: ```md ### BREAKING - `tea issue create`: `-b` moved to `-d` (#101) - remove all teh features! (#303) ### SECURITY - fix CVE (#303) ### ENHANCEMENT - add more CLI flags (#101) ``` The tag used to extract the section could also be an HTML comment ```md   ``` ref gitea/tea#346

noerw added the

feature

label 2021-03-12 04:38:53 +00:00

lunny commented

2021-03-12 04:55:17 +00:00

Currently, we only match with labels, so content keyword search should be another method.

jolheiser commented

2021-03-12 15:23:48 +00:00

imo you should label such PRs kind/breaking (or however you like)

I'm not really a fan of magic comments unless they can be heavily justified.

That being said, perhaps an enhancement where the YAML file can include a bool snippet (or something else, if snippet isn't appropriate) that would grab the first line(s?) of the description and put it in a sub-list, e.g.

fix CVE (#303)
- this fixes CVE-2021-20261

And an example changelog.yml block

groups:
  -
    name: BREAKING
    snippet: true
    labels:
      - kind/breaking

imo you should label such PRs `kind/breaking` (or however you like) I'm not really a fan of magic comments unless they can be _heavily_ justified. That being said, perhaps an enhancement where the YAML file can include a bool `snippet` (or something else, if snippet isn't appropriate) that would grab the first line(s?) of the description and put it in a sub-list, e.g. * fix CVE (#303) * this fixes CVE-2021-20261 And an example `changelog.yml` block ```yaml groups: - name: BREAKING snippet: true labels: - kind/breaking ```

Sign in to join this conversation.