As I wrote in my previous post about automation I would continue my post. So here it is.
The following parts are left from my process:
- Create an issue for myself (if already existing move to step 2)
- Create a branch within the appropriate project based on the issue
- Assign the issue to myself
- Migrate the issue into the state of
- Close the appropriate jira issue with a reference to the commit in comment.
If I work on updates of dependencies or parents in our builds, it is required to make a JIRA ticket for each of those updates (ok not really required but it is useful). It makes sense to test each of those updates separately in Jenkins. In the end it is an important information for the end-users, so they can see what has been changed.
Automation Step 4
The first step is to create a ticket with some information like
a summary, a description and giving
Affected versions and
useful values. This is only needed if we do not have a ticket yet for the
So far I was going into my browser opened the appropriate project and
Create button and typed in the appopriate values. I already
mastered the copy and paste parts from browser url to command line etc.
After some time, I thought about this and came to the conclusion, there must be a more convenient way.
I started to play around with the command line client. There are some things to mention about it:
- Single binary artifact; simply download it and put on the path.
Name it as you like (I decided to name it
- Templating mechanism to create custom commands
- Simple and powerful default commands already existing
- Easy configuration via yaml file.
The first thing is, you need to login into the JIRA instance
which can be handled by the following:
You will be prompted for your password. The user which is used to login is derived by the user you are working with. For me it was wrong. So I needed to add a parameter:
So now I can view a ticket on command line very easy:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Just to take a short look on a particular issue it is much faster than going via the browser.
After more detailed reading the documentation I found that I can put the information
about the end point and the user which should be used for jira into a configuration file
(within your home directory)
.jira.d/config.yml which looks like this:
1 2 3
With this the login command can be reduced to
jira-cli login. Easy? The
jira-cli will safe session information in
.jira.d/ directory which is
cookies.js file. For my convenience I have created a Git repository
.jira.d and added
cookies.js to the
.gitignores file to prevent me to
cookies.js file accidently.
Now I have the ability to create JIRA tickets via command line.
So far so good. But how do I know for which project I need to create a ticket?
But wait a second. The
pom.xml contains the information
project.issueManagement.url which is the URL for the JIRA tracker. So I
needed to find a way to extract it from the
Luckily the maven-help-plugin is here the way to go which looks like this
(Just for brevity I have added
\; usually this is a single line):
1 2 3 4
This will extract the URL for JIRA out of the pom file. So you get something like this:
but unfortunately this is not the project you need for
jira-cli. What I need
MDEPLOY. This can easily achieved by:
These are the information which are needed to create a JIRA ticket.
Hm…really? No. What about the version for
Fixed versions/s and
This can be done by:
1 2 3 4 5 6
This will extract the version out of the pom file without the trailing
-SNAPSHOT. It assumes that the version number has three digits.
So now comes a favorite feature of
jira-cli. You can create your own commands
very easy. You simply define things like this in your
1 2 3 4 5
So now you can simply call
jira-cli like this:
and you will see the list of issues which are assigned to yourself. See more details in the
jira-cli. Based on the above, I have created a custom command which looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
So as the result of this, I can create a JIRA ticket via this:
These have been the prerequisite to finally create a JIRA ticket in a very convenient way. The result of previous things and integrating some other parts is now my createdependencyupgradeissue.sh script which I can simply call like this:
The output of that script looks at the moment like this:
1 2 3 4 5 6 7 8 9
As you might already have realized, I have added things to create a branch in Git based on the JIRA issue name and switched to that branch.
The fourth step of automation accomplished which means more improvement but not enough.
Automation Step 5
If I like to assign a ticket to myself so far I had to go to the
ticket page and click on
assign to me link which prerequisites
to know the issue number and type in the correct URL etc.
So based on my assumptions that the branch name is the JIRA issue number the only thing I need to do, is to extract the number from the branch. This can simply be achieved by:
So next the thing is to assign the ticket to myself. This
can be done with
jira-cli easily like this:
I have to add some sanity checks in case of errors and the result is the takeissue.sh script which I can use within the branch like this:
The fifth step of automation is accomplished which means becoming comfortable but I think, we could do more.
Automation Step 6
This step is more or less identical to the previous one cause I would
like to change the state of an issue into
This can easily be achieved by using
jira-cli like this:
Based on the ideas before, this can be baked into a script startissue.sh which results in such a simple call
The sixth step of automation accomplished which means more improvement is possible.
Automation Step 7
Ok I can create an issue in JIRA including the creation of the branch
in Git so what about to commit here? Usually I update files or add some new
ones which is done by
git add . and afterwards I can commit the state.
So based on the issue the commit message should look like this:
In the majority of the cases I need only the first line. In other words this is copy and paste from the issue I created before. Let us make that easier. I created, of course you know already a script commitonissue.sh which exactly does that.
It identifies the branch based on the name of the branch in Git
and gets the information about the summary via
JIRA which results in such line:
and finally I need to do the real commit which can be handled by this:
The seventh step of automation accomplished which means we are on the home straight. But not yet crossed the line.
Automation Step 8
This step is nothing really new, it is just improving something already existing. The gitmergeclean script of the first post. This is needed to be tweaked. It should also close the JIRA ticket after the branch has been merged to master with an appropriate comment on it.
I have added the following lines to the script to handle this.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
BRANCH information is already extracted at the beginning of the script.
The final lines of the script are to call
jira-cli to close the issue
with an appropriate comment and set the
resolution to a useful value. In our case it is simply
GITURL etc. is extacted to create a useful comment which contains a link to the
real git repository with showing the diff of the commit which has been made.
You can take a look at the MCLEAN-87 issue which shows a link to the git repository.
A full output of the new gitmergeandclean script looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
So finally for a dependency upgrade the process looks like this:
- Change the appropriate information in
createdependencyupgradeissue.sh "Upgrade maven-plugins parent to version 32"
startissue.shAfter that I have to wait for the result of Jenkins. If the build is successful I can merge back to master otherwise I need to find the cause of the problem. In this case the result was successful so I can do it like this:
The output looks in total like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Here is the time where I have to wait for the results of Jenkins. So in this case the result was successful so I can continue like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
So if you look in my previous post you might be astonished that the number process steps has not been reduced dramatically? Those scripts are replacing a large number of manual steps (git command line typing, jira in browser, clicking typing etc.) which is now simply handled by scripts which means the steps are done always in the same way and I am sure I do not forget steps. Furthermore many of scripts can be used in other situations as well which makes my life easier for example in handling pull request etc.
So this was much longer post.