feat(engine): add ci skip directive for docs/chore

[haltcase]

Resolves #23

Add [ci skip] directive automatically for docs and chore commit types.

• the directive is not added if the user already added [ci skip] or [skip ci]
• max line width is taken into account when adding the directive

Note that I also made a couple tiny refactoring changes in order to make the code style more consistent, like padding at the beginning of the function block and spacing between function keyword & parens. Both of these had cases of different styles.

---

Also, and this is unrelated to this PR, but what is the lowest Node environment you're supporting? I considered making a separate PR for a light ES2015 upgrade - it wouldn't have any functional differences but the syntax would be a little cleaner in certain places.

[haltcase]

This doesn't add a prompt to make this an option currently but that's something that can be added easily. Let me know if that's more desired - I personally think having it automatic or at least defaulting to adding it is preferred.

[jimthedev]

@citycide This looks great. This is a pretty significant change so we'll likely need to bump this adapter to 2.0 for this. Although it is a feature, it is one that significantly changes the expectations of the output. This is probably a good thing since we actually have a few other breaking changes that need to be implemented.

To your question about support, we actually had a discussion in the cli repo about this recently. Technically I think the current version works back until node 0.12, but we're likely going to be deprecating that support soon in version 3.0 of the cli. Ulltimately we'll be removing support for version 0.12 in cli version 4.0.

Generally we are open to ES2015 features as long as they are natively supported in node. We are likely removing babel from out build pipeline of the cli to aid in a simpler development cycle. Node/v8 are adding features at a rapid enough pace that we are going to favor stability over being on the cutting edge of syntax. If people want to maintain adapter forks with more complex build structures then that is totally cool with us, but we're going to keep things as lean and simple as possible. Again we're always willing to entertain PRs but hopefully this gives some insight into our thought process.

[haltcase]

All good stuff!

Maybe it would be a good idea to create a milestone or project for the 2.0.0 release here, as there's milestones in the cli for 3.0.0 & 4.0.0. It would be nice to have an idea of what'll change here to keep up with the cli.

[jimthedev]

Yes, luckily there is now a Github projects that span across the entire organization so we can start to use those. One small complaint about the design of that page is that they don't show milestones! https://github.com/orgs/commitizen/projects/1

Also: I have put in a request with Github support to request this feature.

[haltcase]

I get a 404 on that link, but I get you. I actually can't see the Projects tab at all on the org. Funky.

[jimthedev]

Weird, I'll see if there are permissions.

[jimthedev]

Weird, I don't see any permission settings that I can configure.

Github's docs state that if you have read access to the repo. I'm wondering if that is incorrect because when I log out of github and go to the page at I also get a 404... thinking either the docs are wrong.

[jimthedev]

From Github's support team on the subject

Thanks for reaching out! Organization projects can only be seen by organization members. I'll let the Docs team know this could be clearer!

So there it is. I'll need to do some work to get organized but we'll make some things more clear.

[jimthedev]

@citycide I need to add a bunch more info to it to be useful but can you see if you can visit this site: https://waffle.io/commitizen/cz-cli/join

It should have both cli and adapter issues on it now but obviously needs some organization.

[haltcase]

I like that a lot - definitely can get behind this.

In general, what is the roadmap outline for the ecosystem and this PR - is it waiting on anything specific from the cli?

[markdalgleish]

Just noticed this PR, and thought I'd throw in a counter example for this feature.

I manage a living style guide that uses semantic-release, and we continuously deploy our static documentation site on every commit. In our case, we want CI to run when changing documentation.

The core idea here is really great, but I think it would trip people up in scenarios like mine.

[jimthedev]

@markdalgleish thanks for that info. Looks like we'll need to rethink this a bit. Specifically it may be worth providing an option for a repo maintainer to specifically identify those areas where [skip ci] would be added if different from the defaults.

[haltcase]

@jimthedev the simple route would be adding a prompt asking if it should do add the skip tag. But maybe a better, more universal method would be options specified in the package.json config section, and then providing that to plugins like this one. This would require a change in the prompter interface though I think. Something like:

return {
  prompter (cz, context, commit) {}
}

... where context is the config from package.json.

Unless maybe a separate component reads in the config, that can be require'd and called from the engine.

[haltcase]

Checking in since it's been a while - has there been any decision on how config might be handled for this? Or is there anything I can do for this PR currently?

[haltcase]

@jimthedev I pulled, rebased, and made a change to allow for disabling automatic addition of the [ci skip] tag. There's a new prompt that will only appear for docs and chore commit types asking the user (paraphrased) Should CI be skipped?. This defaults to 'yes'.

[haltcase]

It's been a bit - any thoughts still hanging around on this?