Distinguish between `build` and `ci` commit types

[nsenave]

"build" and "ci" commit types are currently treated in the same group in the action.

This has been confusing to me, I used the action with the option:

    excludeTypes: ci,style,chore,other

and expected that "build" commits (that affect my build tool) would be written in the changelog (while I don't want to write about "ci" commits, since changes on the workflow don't affect the delivered code in the end).

Yet, in the logs of the action I had something like this:

Run requarks/changelog-action@v1
Using tag range: ... to ...
[OK] Commit ... of type build - some build commit
[OK] Commit ... of type ci - some ci commit
Selected Types: feat, feature, fix, bugfix, perf, refactor, test, tests, doc, docs

(No build, even if it is not in the excludeTypes)

---

If I get it correctly, the reason is that 'build' and 'ci' are in the same array in allTypes constant:

https://github.com/requarks/changelog-action/blob/669b3359e57e57caa76ec242528e431d4eaf8029/index.js#L17

const allTypes = [
  { types: ['feat', 'feature'], header: 'New Features', icon: ':sparkles:' },
  { types: ['fix', 'bugfix'], header: 'Bug Fixes', icon: ':bug:', relIssuePrefix: 'fixes' },
  { types: ['perf'], header: 'Performance Improvements', icon: ':zap:' },
  { types: ['refactor'], header: 'Refactors', icon: ':recycle:' },
  { types: ['test', 'tests'], header: 'Tests', icon: ':white_check_mark:' },
  { types: ['build', 'ci'], header: 'Build System', icon: ':construction_worker:' },
  { types: ['doc', 'docs'], header: 'Documentation Changes', icon: ':memo:' },
  { types: ['style'], header: 'Code Style Changes', icon: ':art:' },
  { types: ['chore'], header: 'Chores', icon: ':wrench:' },
  { types: ['other'], header: 'Other Changes', icon: ':flying_saucer:' }
]

which causes to filter both if one of the two is selected:

https://github.com/requarks/changelog-action/blob/669b3359e57e57caa76ec242528e431d4eaf8029/index.js#L264

  // -> Filter types
  const types = []
  for (const type of allTypes) {
    if (restrictToTypes.length > 0) {
      if (_.intersection(type.types, restrictToTypes).length > 0) {
        types.push(type)
      }
    } else {
      if (_.intersection(type.types, excludeTypes).length === 0) {
        types.push(type)
      }
    }
  }
  core.info(`Selected Types: ${types.map(t => t.types.join(', ')).join(', ')}`)

---

There is two ways to resolve this:

• add a bit of documentation about it in the readme
• do a little refactor to fix this

It seems to me that the latter would be convenient, I'll link a pull request.

[NGPixel]

This is really just a matter of opinion but the reason build and ci are together is because they are an alias for the same concept. Build is really just a stage of CI and it's not always obvious to the user what's the difference between the two.

Changes to your build tool would be better suited under the chore type (which the angular convention doesn't have). chore is any change that doesn't affect actual production code.

Closing as I prefer to keep the current (opiniated) behavior.

[nsenave]

Thanks for the answer.

I have some cases where editing my build tool config changes my production code:

• the java version of my project is defined in the build config, yet changing it is not a refactor, fix or feat
• updating external dependencies (not for a particular fix or feat, just to stay up to date)

In these cases, the commit cannot be typed as a chore.

My current workaround is to type CI commits (these actually don't change to delivered code) as chore.

The Angular convention makes the distinction between ci and build, so I'm not sure they should be considered as a unique concept. Having those considered the same feels a bit tricky (I've got surprised that exluding ci resulted in excluding build also). At least a little addition in the README would prevent other users from falling in the same trap.

I'm a bit frustrated but that all said, the action is very nice thank you for your work on it.