Automated Changelog using JIRA, GitHub, and Jenkins

Question

My team recently switched to all three technologies in the past several months and have worked hard to get it up and running. Next step is automating our changelogs. We have JIRA set up look for the tags (ex. TAG-123) in github commit messages. Jenkins monitors the GitHub commits on a 5 minute timer, pulls, builds, etc.

What I would like to see is a changelog generated automatically when a build is marked as "Promoted to Production." I would like to see it do something akin to the following:

• Query Jenkins for the previous build marked as a production release and get the corresponding git commit SHA1.
• Run a diff in between the current Git commit and the previous commit
• Find all JIRA tickets that are referenced
• Compile a list of JIRA titles
• Have list export to a text file and placed in build drop (bonus if it can be accessed directly through Jenkins as well)

Whether this flow is followed as written or not is irrelevant--I'm after the end result and am not looking to re-invent the wheel.. Surely somebody done something like this before?

As far as reinvention goes, I was able to find https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin which allows somebody to piggy-back on the Promote to Production action and run a separate script. It would then be a matter of gathering functionality to accomplish the above. (I also noticed Jenkins can tag the current GitHub commit, which my team would likely do in addition.)

Anything closer to accomplishing this would be greatly appreciated.

Thank you!

Answer 1

Since nobody on our team had excess time to devote to this, we ended up throwing together a quick solution.

The Process

1. Install and setup the All Changes plugin for Jenkins.
2. When we release, we use "build promotion" system which puts stars next to the previous build, so we can easily see the build# looking at the history.
3. Copy and paste the relevant output from All Changes into something like notepad++ (human-diff'ing ftw!)
4. Run a regex find/replace. Search on the regex string, replace with an empty string. (below -- there's the big-bang option or its broken up for understandability.)
5. Manually organize and release in whatever form is the current agreed up standard.

Everything at once

(\s*\(commit:\s[a-z0-9]{40}.\s..detail)|([\r][\n]#.*\B[\r][\n][\r][\n])|(^[ \t]*)

Remove commit hash\s*\(commit:\s[a-z0-9]{40}.\s..detail

Remove time and surrounding line breaks[\r][\n]#.*\B[\r][\n][\r][\n]

Removing leading whitespace: ^[ \t]*

The Analysis

Pros:

• Effective overall
• Relatively quick to implement

Cons:

• Not fully automated.
• Need to revert to commit id if you release from multiple Jenkins jobs.
• All Changes history only appears to go back as far as the Jenkins job (I could be mistaken about the specifics of this--I just remember minor grievances with something like this at one point.)

As a whole, the cons are somewhat "the nature of the beast." I'd love to read some other solutions. (For when we have that elusive thing called Time, of course!)

Answer 2

Alternative to dependancy on issue trackers could be to purely use the pull requests themselves. For us they had enough context to generate release notes and we used labels for categorisation. I created PullRequestReleaseNotes and you can try it. It supports GitHub, GitLab, BitBucket and TFS and it can generate release notes in markdown from merged pull requests and its labels and optionally post it to an Atlassian Confluence page and post it to a Slack channel as a post. It can be run as part of continuous integration. Here is a sample:

1.2.1 (MASTER) - XX XXX 2016

Enhancements

Category A

• Awesome new feature #1854

Fixes

Category Z

• Fixed problem with widget #1792

Category Y

• Fixed problem with widget #1792
• Fixed exception with view layout #1848