As with anything UNIX there are a number of ways of getting the job done. To claim one way is more right than another is contentious at best. For instance a recent change connecting GitLab to Jira altered my team’s workflow ever so slightly. The principle are the same for linking Github to Jira and it is really a matter of system your team employs. For my team this is a change that has been a long time coming and it amounted to simply not having enough hours in the day to make improvements. You know the age old problem of the “Developer’s children have no shoes” or some such.
By installing the Gitlab Jira connector developers are not able to reduce the paperwork side of their job connecting the merge requests automatically to the tickets if one follows a simple conventions of including the Jira ticket number in the commit message. The catch is this reference is case sensitive and Jira being Jira like upper case ticket identifiers. My team already has a GitLab push rule that requires every commit message start with the ticket identifier so you can understand that the team has been preparing for this for a long time.
The following is an example of what it look’s like in Jira once connected.
At this point you may be asking yourself what it the big problem this seems all wonderful because the children now have shoes. Developers being highly efficient animals that they are do not like to waste keystrokes so the simple act of typing WP- in lieu of wp- can be rather challenging. In addition there is something that attacks social sensibilities that anything TYPED IN ALL UPPER CASE is harsh and akin to shouting. While I know this is not a huge problem, it is still one worth solving so as to keep my team happy.
I looked at this problem from a number of angles and after determining that the majority of my team is using some form of bash elected to deal with this via simple shell scripting. However to exacerbate things most of the team is still running with Bash 3.2 so I had to look for something relatively universally compatible. One of the other challenges I had to overcome is that we have different ticket prefixes for different boards and projects in Jira so I had to find a solution that would support future growth without much effort.
The following is an example of a standardize commit message as defined by our push rules. They must always start with the ticket number followed by a colon.
“wp-348: Installed the open sourced version of…”
Given this information I started with simple shell script that relies on awk using the – as a field separator to split the string two. As a serendipitous bonus awk provide a series of builtin functions and in this case I was able convert the extracted string to upper case before reassembling it with the rest of the commit message. Finally I passed this to my git commit command followed by a push. The following is what the sample script looks like.
Although it is essentially functional at this point, I felt there is a bit of room for optimization. In addition I wanted to integrate this into my .bash_login as a simple command. Therefore I refactored this into the following;
In the above you see I have converted the previously mentioned script into a BASH function and optimized some of the code. Functionally it is the same except that bash loads this and all the other functions on shell initialization. With this complete I don’t have to remember to chmod +x and script files and my use of bashdoc allows me to type show on the command line to see a list of ALL the commands I have created this way, as demonstrated by the following is an excerpt:
With all this done and my shell reloaded I am now able to type the following command to adjust my commit message in accordance with the new paradigm.
While this is all well and good there is something that gnaws at me about using multiple subshells. In my opinion the first subshell is acceptable since it performs a number of functions all at once but the second is superfluous and somewhat inelegant; therefore, it must be refactored. The following is a cleaner implementation that eliminates the second subshell with some standard bash string manipulation.
I hope that you have enjoyed this discussion and that it has opened you to the possibilities beyond simple shell commands as well as solving that age old problem of: