Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Angular allow al types in changelog without needing a BREAKING CHANGE #838

Open
oalmeyda opened this issue Aug 27, 2021 · 5 comments
Open

Angular allow al types in changelog without needing a BREAKING CHANGE #838

oalmeyda opened this issue Aug 27, 2021 · 5 comments

Comments

@oalmeyda
Copy link

The ability to add other types of commits in release notes is necessary for non-user facing projects.

One possible way is to allow it via environment variables:

--- a/packages/conventional-changelog-angular/writer-opts.js
+++ b/packages/conventional-changelog-angular/writer-opts.js
@@ -33,6 +33,10 @@ function getWriterOpts () {
         discard = false
       })

+         if (process.env.DISCARD_OTHER_COMMIT_TYPES === 'FALSE') {
+           discard = false
+         }
+
       if (commit.type === 'feat') {
         commit.type = 'Features'
       } else if (commit.type === 'fix') {
@baby-gnu
Copy link

I personnaly switch from workaround angular to configured conventionalcommits with the following:

// …
const breakingKeywords = ["BREAKING CHANGE", "BREAKING-CHANGE", "BREAKING CHANGES", "BREAKING-CHANGES"];
const changelogFile = 'docs/CHANGELOG.md';

// https://github.com/conventional-changelog/conventional-changelog-config-spec/blob/master/versions/2.1.0/README.md
const commitTypes = [
  {type: "build",    section: "Build System",             hidden: false},
  {type: "chore",    section: "Maintenance",              hidden: true},
  {type: "ci",       section: "Continuous Integration",   hidden: false},
  {type: "docs",     section: "Documentation",            hidden: false},
  {type: "feat",     section: "Features",                 hidden: false},
  {type: "fix",      section: "Bug Fixes",                hidden: false},
  {type: "perf",     section: "Performance Improvements", hidden: false},
  {type: "refactor", section: "Code Refactoring",         hidden: false},
  {type: "revert",   section: "Reverts",                  hidden: false},
  {type: "style",    section: "Styles",                   hidden: false},
  {type: "test",     section: "Tests",                    hidden: false},
];
// …
  plugins: [
    [
      '@semantic-release/commit-analyzer',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        releaseRules: './release-rules.js',
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
    [
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
  ],
};

// …

See also #421.

@ipleten
Copy link

ipleten commented Mar 28, 2023

I personnaly switch from workaround angular to configured conventionalcommits with the following:

// …
const breakingKeywords = ["BREAKING CHANGE", "BREAKING-CHANGE", "BREAKING CHANGES", "BREAKING-CHANGES"];
const changelogFile = 'docs/CHANGELOG.md';

// https://github.com/conventional-changelog/conventional-changelog-config-spec/blob/master/versions/2.1.0/README.md
const commitTypes = [
  {type: "build",    section: "Build System",             hidden: false},
  {type: "chore",    section: "Maintenance",              hidden: true},
  {type: "ci",       section: "Continuous Integration",   hidden: false},
  {type: "docs",     section: "Documentation",            hidden: false},
  {type: "feat",     section: "Features",                 hidden: false},
  {type: "fix",      section: "Bug Fixes",                hidden: false},
  {type: "perf",     section: "Performance Improvements", hidden: false},
  {type: "refactor", section: "Code Refactoring",         hidden: false},
  {type: "revert",   section: "Reverts",                  hidden: false},
  {type: "style",    section: "Styles",                   hidden: false},
  {type: "test",     section: "Tests",                    hidden: false},
];
// …
  plugins: [
    [
      '@semantic-release/commit-analyzer',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        releaseRules: './release-rules.js',
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
    [
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
  ],
};

// …

See also #421.

Can you please elaborate a bit how to use this?
I'm trying to add conventional commits with additional types to lerna and can't find any documentation.

@baby-gnu
Copy link

Can you please elaborate a bit how to use this? I'm trying to add conventional commits with additional types to lerna and can't find any documentation.

Hello.

You can find a complete example of configuration in my ci-tools .releaserc.js config file.

With the following diff, you could add a foo keyword to generate a Foo section section which trigger a patch level version bump:

commit 2728e059c8e5b82b2e86a0b2e6d2e2924780116e
Author: Daniel Dehennin <daniel.dehennin@ac-dijon.fr>
Date:   Wed Mar 29 08:40:12 2023 +0200

    foo(semantic-release): try the foo section

diff --git a/.releaserc.js b/.releaserc.js
index a4cff44..5b18882 100644
--- a/.releaserc.js
+++ b/.releaserc.js
@@ -45,6 +45,7 @@ const commitTypes = [
   { type: "revert",   section: "Reverts",                  hidden: false},
   { type: "style",    section: "Styles",                   hidden: false},
   { type: "test",     section: "Tests",                    hidden: false},
+  { type: "foo",      section: "Foo section",              hidden: false},
 ];
 
 const releaseRules = [
@@ -60,6 +61,7 @@ const releaseRules = [
   { type: 'revert',     release: 'patch' },
   { type: 'style',      release: 'patch' },
   { type: 'test',       release: 'patch' },
+  { type: 'foo',        release: 'patch' },
 ];
 
 const semanticBranches = [stableBranch];

When running semantic-release, I got:

semantic-release --dry-run --branches $(git symbolic-ref --short HEAD)

[6:52:13 AM] [semantic-release] › ℹ  Running semantic-release version 19.0.3
[…]
[6:52:21 AM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[6:52:21 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: foo(semantic-release): try the foo section
[6:52:21 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[…]
[6:52:21 AM] [semantic-release] › ℹ  Release note for version 1.0.0:
## 1.0.0 (2023-03-29)

### Features

[…]

### Foo section

    * semantic-release: try the foo section (2728e05 (https://gitlab.com/baby-gnu/ci-tools/commit/2728e059c8e5b82b2e86a0b2e6d2e2924780116e))

Note that I did not yet look for the way to change the sorting order.

Regards.

@baby-gnu
Copy link

Note that I did not yet look for the way to change the sorting order.

Found it 😉

@baby-gnu
Copy link

Note that I did not yet look for the way to change the sorting order.

Found it wink

The sorting order can be done quite simply on the ordering of the commitTypes array:

diff --git a/.releaserc.js b/.releaserc.js
index 5b18882..86eb6e2 100644
--- a/.releaserc.js
+++ b/.releaserc.js
@@ -47,6 +47,11 @@ const commitTypes = [
   { type: "test",     section: "Tests",                    hidden: false},
   { type: "foo",      section: "Foo section",              hidden: false},
 ];
+// Group commit by type and sort the sections according to `commitTypes` sorting
+const commitGroups = commitTypes.map((e) => { return e.section; });
+function commitGroupsSortFn(a, b) {
+  return commitGroups.indexOf(a.title) - commitGroups.indexOf(b.title);
+};
 
 const releaseRules = [
   { breaking: true,     release: 'major' },
@@ -115,6 +120,10 @@ const config = {
         {
           noteKeywords: breakingKeywords,
         },
+        writerOpts:
+        {
+          commitGroupsSort: commitGroupsSortFn,
+        },
         presetConfig:
         {
           types: commitTypes,

Changing the order of commitTypes elements will modify the changelog sections ordering automatically.

Thanks for your question, it gave me the opportunity to look for the solution 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@baby-gnu @ipleten @oalmeyda