Automate your versioning (part 2)

As promised, here is the second part of the series for automating your versioning.

EDIT: Below I am posting the links for the complete series, if you want read it all:

In the first part, I discussed mainly about the standardization of the commits and why they are so important.

But it is a bit boring that during every commit you need to make sure you are typing correctly.

Reading the Conventional Commit specification you can get to the part where it lists a bunch of tools you may use to enforce the usage of the commit convention.

Choosing a tool

I experimented a few tools, and I came up with a good one that currently is fitting all my needs.

This tool is based on Node.js. So, the first thing you want to do, is download the latest stable version of node environment according to your OS.

Website for Node JS

You are probably asking yourself. Will I need develop javascript? Why not python tools?

Yeah yeah, relax, we are going to download only ready to use libraries and executables, so you don’t have to worry about knowing javascript (eventually you would want to contribute to the projects, but it is a specific use case).

Python have pretty good tools too, but I felt more comfortable with the node tools.

Installing NodeJS

If you are in Windows you should have some attention to destination folder. I usually use a folder in the root of the disk c:\applications, where I install as Administrator some tools for developing, such as git, node, and others. In my experience I had trouble with directories a bit far from the root, and with space in path. So, you’d rather avoid it.

Installing Git

Just emphasizing, you probably have already installed, buuut, just listing as a step.

Install the Lint Tool

After installing everything you can open the git bash and try this command.

npm --version

This command checks for the Node Package Manager version, if it responds so you are good to go.

With your hands still in bash, install (globally) the commit lint tool.

npm install -g @commitlint/cli @commitlint/config-conventional

The usage of the tool is usually pretty straight forward, and some description is in the website. But the way it is described there it is not very good for my daily usage. So I configured the git to use this tool automatically.

Configuring your git

Creating a Git Global Hook

There are many ways of creating a global hook, but I am going to show how I did it.

Inside that folder for applications and I created another folder called “hooks”. So the path stayed like this:

c:\applications\hooks

Then, after completing that step, you configure globally (or not, I am assuming you know the difference between a global and local config) the git for the hook path.

git config --global core.hookspath c:/applications/hooks
git config --global core.hookspath

Yes. The slash is forward (because of bash). So, hooks path set, now let’s configure our commit message hook.

Create two files inside the hook folder and insert the content:

  • one called “commit-msg” (without extension)
#!/bin/bash
npx commitlint -e --verbose --config c:/applications/hooks/commitlint.config.js
  • second one called “commitlint.config.js”
module.exports = {extends: ['@commitlint/config-conventional']}

Explaining:

The first one is used for analyzing your commit message. For doing this it uses a predefined standard, which is the second file.

In this case we are using Conventional Commit Style. But if you are curious there are other styles too.

Using

After all this configuration, you can use now in all your commits.

I mean, now this tool will prohibit you to commit non standardized messages. If you try to commit wrong, this tool you point the error.

Example:

x input: some message
x subject may not be empty 
x type may not be empty 
x found 2 problems, 0 warnings

After that, your commit message you be discarded, forcing you to rewrite one that is compatible.

Even me, after a while using, sometimes I have some mistakes writing, so it is normal to fail in the test occasionally.

x input feat: adds a button to close the application
x found 0 problems, 0 warnings

Now, you may asking yourself. What if I just want to commit ? No messages, no boring stuff.

So, the solution is to bypass the commit message hook, using another option.

git commit --no-verify

Why would you want to mess up all your standardized messages?

I can list two reasons:

  • You just want to save a position of your code, but you haven’t finished any feature or bugfix. So, you can use this option. The message will be ignored by the commit parser later.
  • You are testing something that needs to be committed, and later you will clean your commit history by squashing your commits (i.e. using rebase).

Those are valid options, but in the end it will depends on your workflow, but keeping a standard is important, because will help us to bump the versions, as I will explain in my third part of this series.

Until then…

BONUS TIP:

I replayed all this configuration in a Windows Sandbox, so I am pretty sure it works. If you haven’t heard of it, it is a good application for testing installers and even maybe potential malicious applications.

3 thoughts on “Automate your versioning (part 2)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s