Any way to include the Jira ticket using git-cz --non-interactive ?

Why?
I'm working for a client where we are using Jira for our tickets and Azure DevOps for repo, and pipelines.
When I configure the following tools to make the build, release and ticket integrations work:
https://marketplace.atlassian.com/apps/4984/git-integration-for-jira?hosting=cloud&tab=overview
https://marketplace.atlassian.com/apps/1220515/azure-pipelines-for-jira?hosting=cloud&tab=overview

Through my testing I've found:
That the deployments are only linked to the Jira tickets if the Jira ticket reference is in the header of the commit
That the links to the commits in Jira tickets are only present if the Jira ticket reference is in the footer of the commit

Go figure?
So to get what I'm looking for (navigability from Jira to Azure DevOps for issues, builds, releases) I need it both places.

For my own purposes it was easy enough to modify what you have to make that work by doing the following:
(only code changed is under the comment, provided the rest for context)

var getJiraIssueLocation = function(location, type, scope, jiraWithDecorators, subject) {
    switch(location) {
      case 'pre-type':
        return jiraWithDecorators + type + scope + ': ' + subject;
        break;
      case 'pre-description':
        return type + scope + ': ' + jiraWithDecorators + subject;
        break;
      case 'post-description':
        return type + scope + ': ' + subject + ' ' + jiraWithDecorators;
        break;
      case 'post-body':
        // return type + scope + ': ' + subject;
        return type + scope + ': ' + jiraWithDecorators + subject;
        break;
      default:
        return type + scope + ': ' + jiraWithDecorators + subject;
    }
  };

and

{
    type: 'limitedInput',
    name: 'subject',
    message: 'Write a short, imperative tense description of the change:',
    default: options.defaultSubject,
    maxLength: maxHeaderWidth - (options.exclamationMark ? 1 : 0),
    leadingLabel: answers => {
      // const jira = answers.jira && options.jiraLocation !== 'post-body' ? ` ${answers.jira}` : '';
      const jira = answers.jira && options.jiraLocation !== 'post-body' ? ` ${answers.jira}` : ` ${answers.jira}`;
    
      let scope = '';
      const providedScope = getProvidedScope(answers);
      if (providedScope && providedScope !== 'none') {
        scope = `(${providedScope})`;
      }
    
      return `${answers.type}${scope}:${jira}`;
    },
    validate: input =>
      input.length >= minHeaderWidth ||
      `The subject must have at least ${minHeaderWidth} characters`,
    filter: function(subject) {
      return filterSubject(subject);
    }
},

But obviously if you were looking to add as an enhancement you would want to provide it as a whole other option and do it properly.
It isn't clear however how you might want to do that as once you start considering an option of both you then double the options that you currenlty offer (pre-type and post-body), (pre-description and post-body) ... and it starts to get a bit unweildy.

For what you consider an edge case it might not be worth it for you but I thought I would post this anyway for you to consider.
For now my simple hack works for me.

When we run npm audit in the project with this lib, will be show following warning

set-value  <4.0.1
Severity: high
Prototype Pollution in set-value - https://github.com/advisories/GHSA-4jqc-8m5r-9rpr
No fix available
node_modules/set-value
  cache-base  >=0.7.0
  Depends on vulnerable versions of set-value
  Depends on vulnerable versions of union-value
  node_modules/cache-base
    base  >=0.7.0
    Depends on vulnerable versions of cache-base
    node_modules/base
      snapdragon  0.6.0 - 0.10.1
      Depends on vulnerable versions of base
      node_modules/snapdragon
        braces  2.0.0 - 2.3.2
        Depends on vulnerable versions of snapdragon
        node_modules/git-branch/node_modules/braces
        expand-brackets  1.0.0 - 2.1.4
        Depends on vulnerable versions of snapdragon
        node_modules/expand-brackets
        extglob  1.0.0 - 2.0.4
        Depends on vulnerable versions of snapdragon
        node_modules/extglob
        micromatch  3.0.0 - 3.1.10
        Depends on vulnerable versions of snapdragon
        node_modules/git-branch/node_modules/micromatch
          findup-sync  2.0.0 - 3.0.0
          Depends on vulnerable versions of micromatch
          node_modules/git-branch/node_modules/findup-sync
            git-branch  >=2.0.0
            Depends on vulnerable versions of findup-sync
            node_modules/git-branch
              @digitalroute/cz-conventional-changelog-for-jira  *
              Depends on vulnerable versions of commitizen
              Depends on vulnerable versions of git-branch
              node_modules/@digitalroute/cz-conventional-changelog-for-jira
        nanomatch  >=0.1.1
        Depends on vulnerable versions of snapdragon
        node_modules/nanomatch
  union-value  *
  Depends on vulnerable versions of set-value
  node_modules/union-value

The git-branch did not updated in four years. I saw a PR to resolve the security issue in last year, but not merge yet. looks git-branch is not maintain any more.

I suggest use simple-git to replace it. it is a more popular and more activities npm packages than git-branch

AFAICT this plugin can only put the Jira ID at the start of your message. It would be amazing if you could offer a few variants, i.e.

Prefix

(default, current)

feat(scope): JIRA-123 some commit message

Suffix

Akin to the commonly used merge format ... (#1)

feat(scope): some commit message (JIRA-123)

Body

To follow the Conventional Commit standard

feat(scope): some commit message

JIRA-123

At the moment it seems that the link in changelog is generated like this:

[1c1fd85](http://bitbucket.org/my-workspace/my-repo/commit/1c1fd85191017fec3002fbb565ed2a8be00b8b1b)

This link doesn't work because the correct one is http://bitbucket.org/my-workspace/my-repo/commits/1c1fd85191017fec3002fbb565ed2a8be00b8b1b (commits in plural form).

Not getting type of change option during commit from newer version. Is there a new flag for enabling this?
Screenshot -> https://drive.google.com/file/d/1TpF4flxAhVagIrQyodH9Jq88UyPJjBMX/view?usp=sharing

Hi, when devs at my outfit merge a branch into the working branch, they get the commitizen prompts as expected, but they end up with Merge branch <such-and-so> into <working branch> as the commit message anyway, obviating effort put into satisfying the interactive commit.

Is there some configuration I am doing incorrectly? I'm using Husky, if it matters. Here is the Husky config for prepare-commit-msg:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

exec < /dev/tty && npx cz --hook || true

Update commit template for Optional JIRA ID.

Reason: Some times and on specific cases its required save some changes skiping add this field

If jiraLocation could put the issue ID to the end of the body in a key-value like format, then git interpret-trailers could understand it. This would make processing the commit message with scripts easier.

It would be great if the JIRA's URL could be specified with the config as well, so a commit message could look like this:

fix(foo): baz no longer produces invalid value

JIRA-ID: ASDF-1234
JIRA-Link: https://my-jira-instance.example.com/browse/ASDF-1234

Feature Request

Detail

Provide a scopeOptional parameter as part of config. When no scopes object is provided, this should behave as current (user enters custom, or nothing to skip). When a scopes object is provided, the selection should be prefaced by another interactive question, e.g. "Does this commit have scope?" (ideally this should be customisable too). If (y), then provide scope selection. If (n), skip the scope.

Use Case

When working on a library of components, scope could be used to provide more context to the component being updated within the commit. Providing the list of applicable components is a useful feature. However, when a change is made that sits outside of any given component, e.g. updating build tools, scope is not appropriate for this change.

🚨 The automated release from the beta branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the beta branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Hi,

I have the following configuration:

.cz.json file (equivalent to config.commitzen.path in package.json):

{
	"path": "./changelog.config.js"
}

I also have the following changelog.config.js file:

const custom = require('@digitalroute/cz-conventional-changelog-for-jira/configurable');

module.exports = custom({
	disableEmoji: false,
	list: ['test', 'feat', 'fix', 'chore', 'docs', 'refactor', 'style', 'ci', 'perf'],
	maxMessageLength: 65,
	minMessageLength: 3,
	types: {
		chore: {
			description: 'Build process or auxiliary tool changes',
			emoji: '🤖',
			value: 'chore',
		},
		ci: {
			description: 'CI related changes',
			emoji: '🚀',
			value: 'ci',
		},
		docs: {
			description: 'Documentation only changes',
			emoji: '📘',
			value: 'docs',
		},
		feat: {
			description: 'A new feature',
			emoji: '🔥',
			value: 'feat',
		},
		fix: {
			description: 'A bug fix',
			emoji: '🐞',
			value: 'fix',
		},
		perf: {
			description: 'A code change that improves performance',
			emoji: '⚡️',
			value: 'perf',
		},
		refactor: {
			description: 'A code change that neither fixes a bug or adds a feature',
			emoji: '💡',
			value: 'refactor',
		},
		release: {
			description: 'Create a release commit',
			emoji: '🔖',
			value: 'release',
		},
		style: {
			description: 'Markup, white-space, formatting, missing semi-colons...',
			emoji: '🎨',
			value: 'style',
		},
		test: {
			description: 'Adding missing tests',
			emoji: '✅',
			value: 'test',
		},
	},
	skipScope: true,
});

I have the required packages installed:

		"@commitlint/cli": "16.2.3",
		"@commitlint/config-conventional": "16.2.1",
		"@digitalroute/cz-conventional-changelog-for-jira": "7.2.1",
		"commitizen": "4.2.4",
		"cz-conventional-changelog": "3.3.0",

But yet, when I do "npx git-cz" I can't see the emoijs:

Error for following message : Commit message: [CC-588] feat: haha

It works for most jira issues, like:

 PROJ1-23424

But if the jira issue is like:

BIZ_PROJ2-2342 

It will not let me set that jira id. My guess it does not like the underscore in the jira issue. Any way to allow an underscore in the name?

First of all, I wanted to thank you for the awesome work on this library. I've been looking for something similar for weeks, and your repo seems really helpful.

There are just a couple of things that I'd like to adjust to match my use case. I thought it'd make sense to have a chat with you before doing the work and creating a PR with the code that might not work as you'd like.

Here are the questions I have:

1. Why are the configs supported via the environment variables? Is there a use case you encountered where that's useful, or is it just a rule for any Commitizen extension? Supporting env variables limits configuration since we can't pass in things like Arrays and Objects.
2. Would you be open to me adding a few things to the config? Here are a few things that I think would be good to make customisable:
   2.1. The placeholder Jira ticket prefix - currently it falls back to DAZ-12345. It'd be good to make it a variable in config, e.g. (MY -> MY-12345)
   2.2. Scopes - this one is a bit trickier because it calls for an array, e.g. ['scope1', 'scope2'] so it wouldn't be supported by the env variable method
   2.3. Types - currently the types are being read from types.js. Same issue as the above point though, env variables would be tricky.
3. Would you be open to making an extendable version that takes in the config? I'd like to create a util where I configure your library, and then use that util in all my projects.

Ideally it'd work something like this:
@mylibrary/commitizen-config/index.js

const czConventionalChangelogForJira = require('digitalroute/cz-conventional-changelog-for-jira/extendable.js');
module.exports = czConventionalChangelogForJira({
  maxHeaderWidth: 100,
  jiraTicketPrefix: 'MYJIRA'
  // ETC
});

And then I could use it like so:
package.json

"config": {
    "commitizen": {
      "path": "./node_modules/@mylibrary/commitizen-config"
    }
  }

Additionally, if we go for the approach of making the config extendable, what would be the best way to structure the code to avoid duplication and still maintain support for the ENV variables approach?

Very curious to hear your thoughts.

Thanks!

Hi,
would it be possible to leave more freedom in creating the jira prefix so that we don't always have to use the "-" after the tag?
This is probably the jira standard but if you were free to enter "#" for example, it could also be used in other contexts:

jiraPrefix: 'AB#',

Enter JIRA issue (AB#-12345) (optional): AB#2224

The body of the commit message should accept multiline comments, i.e. paragraphs. According to commitizen/cz-cli#398, the body type should be editor, instead of input. I can provide a PR if needed.

See the latest action: https://github.com/digitalroute/cz-conventional-changelog-for-jira/actions/runs/1682733074

The error seems to be this: SemanticReleaseError: Cannot push to the Git repository. and I don't know what has changed. Could we try resetting the secret GITHUB_TOKEN and see if that works? I recently deleted a private token that I thought was related to something completely else. It is very unlikely that my token was used for this repo but I am not 100% sure.

What do you think @polarn?

I'm using commitlint with @commitlint/config-conventional which only allows lowercase subjects. Since this adapter converts the Jira prefix to uppercase, it fails linting when using the default jiraLocation: 'pre-description'. I've solved this for now by disabling the subject-case rule, but I would prefer to leave it intact, so I would really appreciate an option to not convert anything to uppercase. Even better would be an option to convert it to lowercase if it's typed in uppercase 🙂

Regex currently only allows 1 JIRA issue per commit. Sometimes one commit may affect multiple issues.
Even though it's recommended to keep commits atomic, commits with multiple issues should still available as an option, maybe with a strong warning.

https://stackoverflow.com/questions/68448567/cz-conventional-changelog-for-jira-set-up-with-husky-v7-is-not-working

"@digitalroute/cz-conventional-changelog-for-jira": "^6.5.0", "husky": "^6.0.0",

After running git commit I will get:

`Could not resolve cz-conventional-changelog-for-jira. Cannot find module 'cz-conventional-changelog-for-jira'
Require stack:

• /Users/neginbasiri/Projects/web-ui/node_modules/commitizen/dist/commitizen/adapter.js
• /Users/neginbasiri/Projects/web-ui/node_modules/commitizen/dist/commitizen.js
• /Users/neginbasiri/Projects/web-ui/node_modules/commitizen/dist/cli/git-cz.js
• /Users/neginbasiri/Projects/web-ui/node_modules/commitizen/bin/git-cz.js
• /Users/neginbasiri/Projects/web-ui/node_modules/commitizen/bin/git-cz`

If I change path in .czrc from "path": "cz-conventional-changelog-for-jira", to "path": "cz-conventional-changelog",
It works perfectly. So something is wrong with the "cz-conventional-changelog-for-jira"

Expected Behavior

When I set jiraPrefix in package.json config.commitizen
I expect the jira issue sample to use the entered prefix (Enter JIRA issue (DAZ-12345))

Current Behavior

Its always displaying the default prefix(DAZ).

Hi
I was wondering if it were possible to extend the configuration to provide customScope : true option along with scopes.

This would allow users to provide custom scope aside from the ones provided in the list.

I will submit a PR as a proof of concept for You to review

Thanks
Tomasz

Hi there,

Big fan of this commitzen configuration.

I tried applying it to a new repo I started and noticed that it would fail...

git cz
[email protected], @digitalroute/[email protected]

? Select the type of change that you're committing: feat:     A new feature
? Enter JIRA issue (DAZ-12345) (optional): 
? Write a short, imperative tense description of the change: 
  [------------------------------------------------------------------------] 66 chars left
   feat: (node:972436) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'then' of undefined
    at /home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/inquirer/lib/ui/prompt.js:88:32
    at Observable._subscribe (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/observable/defer.js:10:21)
    at Observable._trySubscribe (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/Observable.js:44:25)
    at Observable.subscribe (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/Observable.js:30:22)
    at Object.innerSubscribe (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/innerSubscribe.js:102:23)
    at MergeMapSubscriber._innerSub (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/operators/mergeMap.js:80:50)
    at MergeMapSubscriber._tryNext (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/operators/mergeMap.js:74:14)
    at MergeMapSubscriber._next (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/operators/mergeMap.js:57:18)
    at MergeMapSubscriber.Subscriber.next (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/Subscriber.js:66:18)
    at MergeMapSubscriber.notifyNext (/home/john/.nvm/versions/node/v12.22.3/lib/node_modules/commitizen/node_modules/rxjs/internal/operators/mergeMap.js:93:26)
(node:972436) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:972436) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I noticed that this only started happening after i began using vorpal (https://github.com/dthree/vorpal)

If I remove Vorpal, everything works great.

Here's what my package.json looks like:

{
  ...
  "dependencies": {
    "dotenv": "^10.0.0",
    "knex": "^0.95.14",
    "mongoose": "^6.0.13",
    "mysql2": "^2.3.3",
    "ts-node": "^10.4.0",
    "typescript": "^4.5.2",
    "vorpal": "^1.12.0"
  },
  "devDependencies": {
    "@commitlint/cli": "13.2.1",
    "@commitlint/config-conventional": "13.2.0",
    "@digitalroute/cz-conventional-changelog-for-jira": "6.6.0",
    "@types/knex": "^0.16.1",
    "@types/mongoose": "^5.11.97",
    "@types/vorpal": "^1.12.2",
    "husky": "^7.0.4"
  },
  "commitlint": {
    "extends": [
      "@commitlint/config-conventional"
    ]
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/@digitalroute/cz-conventional-changelog-for-jira",
      "jiraOptional": true,
      "jiraPrepend": "[",
      "jiraAppend": "]"
    }
  }
}

I'm using:
yarn @ 1.22.17
node @ 12.22.3 (also tried with v14.18.1)

I would like to use commitizen with cz-conventional-changelog-for-jira and also set it up with commitlint

Having installed git-cz and following config in ~/.czrc

{ "path": "@digitalroute/cz-conventional-changelog-for-jira", "jiraPrefix": "ABC", "skipScope": false }

I tried to run commitlint to verify recent commit using npx commitlint -e and following commitlint.config.js

module.exports = {extends: ['@digitalroute/cz-conventional-changelog-for-jira']};

and encountered error:

✖   Please add rules to your `commitlint.config.js`
    - Getting started guide: https://commitlint.js.org/#/?id=getting-started
    - Example config: https://github.com/conventional-changelog/commitlint/blob/master/%40commitlint/config-conventional/index.js [empty-rules]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

As my project is not node oriented, I would like to keep node dependencies out of my repository.

Is there any option I could run lint using rules from @digitalroute/cz-conventional-changelog-for-jira ?

Is it possible translate questions about type, scope and all other?

Currently the automatic branch name detection only works if the branch has a matching jiraPrefix
example:

• feature-daz-1234-branch-name // does not work
• feature-DAZ-1234-branch-name // detects DAZ-1234

Hi! Can you share your commitlint config which validating Jira issue after type, like in your template:
feat: DAZ-12345 commit message

After setting jiraLocation: 'post-body' jira task is completely removed from commit.
I use dynamic configuration.
Configuration:

CLI preview:

Is there any guidance on commitlint with this library? The subject-case rule fails when we put the jira ticket in the subject. Right now I just disable that rule and it works but it be good to get some advice what you all did?

We're trying to replace a custom commit-msg hook that used the branch names to add JIRA issues to the front of our commits with a commitizen/commitlint setup. Right now, we can't add any of the other of conventional-changelogs features yet but would like to already start using commitizen for our current convention.

Since there is already a skip option for most things, adding a skipType as well would allow us to just plug in commitizen right now.

As described in in an issue in the upstream repository, according to conventional commits, a breaking change can also be denoted by adding an exclamation mark (!) after type / scope.
This improves the visibility of breaking changes by making them visible in the commit message header.

fix(api)!: omit keys of undefined elements in JSON responses

BREAKING CHANGE: < reason here >

I'll open a PR which adds an option to enable this behaviour.
A code review would be highly appreciated.

Thanks in advance for the great work so far!

I am just setting up this and really enjoying being able to connect the dots. GitHub branch gets pulled into the commit and in the commit body. I also really appreciate being able to specify the allowable scopes.

One thing that is a bit strange is that the description always shows the JIRA ticket and doesn't allow me to use those characters.

Config:

{
  "maxHeaderWidth": 72,
  "path": "@digitalroute/cz-conventional-changelog-for-jira",
  "scopes": ["readme", "gha", "base"],
  "skipScope": false,
  "jiraLocation": "post-body"
}

The result is this:

You can see that the final output has the jira item in the correct location, while the description input includes it in the line.

With jiraLocation set to pre-type, and using jiraPrepend and jiraAppend, when you get to the following step, the configuration is not reflected in the preview.

With:

  jiraLocation: 'pre-type',
  jiraPrepend: '[',
  jiraAppend: ']',

Actual:

Write a short, imperative tense description of the change:
  [------------------------------------------------------------------------] 56 chars left
   deps(npm): GS-6 resolves missing peer dependencies

Expected:

Write a short, imperative tense description of the change:
  [------------------------------------------------------------------------] 56 chars left
   [GS-6] deps(npm): resolves missing peer dependencies