Isseucheck aims to provide commandline services to programmers who need to embed issue id’s in their commit messages.
- Why issuecheck?
- What can issuecheck do for you today?
- Configure your git client repo
- Alternatives to the command line options
- The code
- Known issues
More and more code is kept in sourcecode repositories. Changes to code is managed in issue tracking systems. Linking those two worlds is often done by referring to issues in commit messages.
Commit messages are often written in a coding state of mind. Coming up with the right issue id to put in the message is often felt as an unwelcome distraction.
This tool aims to allow coders to stay focussed while referring to the right issues without having to change context by going into some gruesome webinterface to find the right issue number.
Issuecheck aims to be unobtrusive. This means:
- helping and not claiming
- lean and mean
- easy to install
- rock solid
It provides a convenient way to (inobtrusively) inform you about JIRA issue keys that you might put in your commit messages to your SCM software.
It provides fast answers on the commandline to the following questions:
- Does my commit message contain JIRA issues keys that comply to regex “[A-Z][A-Z0-9_]*?-[0-9]*” ?
- Are the JIRA issue keys I refer to part of a project that I want to commit to?
- Do the JIRA issues that I refer to, exist on my JIRA system?
- What is the type, status and summary of the JIRA issues I refer to?
- Are the JIRA issues that I refer to, resolved?
It will return an exit status of your choice so you can inform, warn or stop yourself when committing code.
One way to find out what issuecheck can do is to play around with it.
simply doing “issuecheck –[tab][tab]” will give you some options.
The output of issuecheck -h:
issuecheck -h
Allowed options:
-h [ --help ] produce help message
-e [ --endpoint ] arg absolute url to jira rest endpoint ending
with ...rest/api/2 (no slash)
-u [ --userid ] arg a JIRA userid
-p [ --password ] arg a JIRA password
-N [ --not-require-issue-key ] do not require that at least one JIRA issue
key is found in the message
-E [ --require-existing ] require all JIRA issue keys to represent
existing JIRA issues (and get issue from
server to find out)
-U [ --require-unresolved ] require all JIRA issues to be unresolved (and
get issue from server to find out)
-S [ --show-issue-summary ] show issue summary (and get issue from server
to get them)
--project-keys-allowed arg alow only JIRA issue keys that have one of
[arg [arg]] as its JIRA project key
--project-keys-preferred arg warn if JIRA issue keys do not have one of
[arg [arg]] as their JIRA project key. If the
project-keys-allowed option is used, these
keys must also be mentioned there.
-f [ --file ] arg use the contents of file [arg] as the message
and ignore standard input
-m [ --message ] arg use [arg] as the message and ignore standard
input
--list-long-options List all the long options
I like to get some feedback when committing locally. Git allows me to integrate issuecheck very easily:
in my repo there is a hidden folder called .git. In this folder, I make a new file called .git/hooks/commit-msg. commit-msg is called by git after I type my commit message but before it is actually committed.
I have a few choices when I use issuecheck in combination with git. Below are a few examples:
- If I want to inform myself about the issues I put in my commit messages
#!/bin/bash issuecheck --file $1 --not-require-issue-key --project-keys-preferred FOO BAR # expected error_status == 0 exit
This will tell me if I forget to refer to an issue and that my issue is not in the projects FOO or BAR. It will never stop my commits. If I want to improve my commit message I will simply use “git commit –amend” after I notice shortcomings. The output from “issuecheck” will be shown to me as part of the git commit output.
- If I want ensure that I commit sensible JIRA issues
#!/bin/bash issuecheck --file $1 --project-keys-allowed FOO BAR # expected error_status > 0 if requirements are not met exit
This will only allow commits that have JIRA issue keys in them that start with FOO or BAR.
- If I want to see the titles of the JIRA issues that I put in my commit messages
#!/bin/bash issuecheck --file $1 --not-require-issue-key --project-keys-preferred FOO BAR \ --endpoint https://[myjirahost]/.../rest/api/2 --userid thovel --password xxxxxx # expected error_status == 0 exit
This will work like #1 and also show me the titles of the JIRA issues that I typed if they were found on my JIRA server.
If you use issuecheck alot you might grow tired of all the program option typing. For this reason issuecheck allows you to organize your options a bit.
The following lines might be in your .bashrc or .profile
ISSUECHECK_USERID=thovel export ISSUECHECK_USERID ISSUECHECK_PASSWORD=xxxxx export ISSUECHECK_PASSWORD ISSUECHECK_ENDPOINT=https://[myjirahost]/.../rest/api/2 export ISSUECHECK_ENDPOINT
you can use all the options in ~/.issuecheck that you use on the commandline.
Here is a template for ~/.issuecheck
## endpoint=arg ## absolute url to jira rest endpoint ending with ...rest/api/2 (no slash) # endpoint= ## userid=arg ## a JIRA userid # userid= ## password=arg ## a JIRA password # password= ## not-require-issue-key true|false ## do not require that at least one JIRA issue key is found in the message # not-require-issue-key=false ## require-existing ## require all JIRA issue keys to represent existing JIRA issues ## (and get issue from server to find out) # require-existing=false ## require-unresolved ## require all JIRA issues to be unresolved (and get issue from ## server to find out) # require-unresolved=false ## show-issue-summary ## show issue summary (and get issue from server to get them) # show-issue-summary=false ## project-keys-allowed [arg [arg]*] ## alow only JIRA issue keys that have one of [arg [arg]] as its JIRA project key # project-keys-allowed= ## project-keys-preferred [arg [arg]] ## warn if JIRA issue keys do not have one of [arg [arg]] as their JIRA project key. ## If the project-keys-allowed option is used, these keys must also be mentioned there. #--project-keys-preferred arg
I made issuecheck when I was searching for a simple challenge to aquaint myself with C++11 and boost C++ libraries. issuecheck contains all I wanted to learn for now.
- C++11
- cmake
- cpack
- cpp_netlib
- Boost program options
- Boost regex
- Boost filesystem
- Boost encode
- Boost uri
- Boost property tree (json)
- Boost function
- Boost archive
- Google test
You might get this error when running issuecheck:
terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid
It happens when a language in your “locale” of your shell is not generated by locale-gen on your system. This often happens to me when I ssh into some system. My ssh client forwards my local locale to the remote shell that might not speak my language.
The Boost libraries that I use are vulnerable to this. The Boost guys know and I guess they will fix it eventually.
- find out what your local is
-
run this command on your prompt:
localeon my system it gives me something like this:
LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC=nb_NO.UTF-8 LC_TIME=nb_NO.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=nb_NO.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=nb_NO.UTF-8 LC_NAME=nb_NO.UTF-8 LC_ADDRESS=nb_NO.UTF-8 LC_TELEPHONE=nb_NO.UTF-8 LC_MEASUREMENT=nb_NO.UTF-8 LC_IDENTIFICATION=nb_NO.UTF-8 LC_ALL=In this case I have en_US.UTF-8 and nb_NO.UTF-8
- install the locales (they might already be there but that does not matter)
-
by doing:
sudo locale-gen en_US sudo locale-gen en_US.UTF-8 sudo locale-gen nb_NO sudo locale-gen nb_NO.UTF-8 - verify
-
locale -a | sed -n -e '/nb_NO/p' -e '/en_US/p'gives me:
en_US en_US.iso88591 en_US.utf8 nb_NO nb_NO.iso88591 nb_NO.utf8
now it should all work
run this every time after you log into your system
export LC_ALL="en_US.UTF-8"
Stop forwarding locale from your client /etc/ssh/ssh_config, comment out
#SendEnv LANG...
stop accepting on the server /etc/ssh/sshd_config , comment out
#AcceptEnv LANG LC_*