- Notifications
You must be signed in to change notification settings - Fork32
Creates a changelog, or release notes, based on Git commits between 2 revisions.
License
jenkinsci/git-changelog-plugin
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
Creates a changelog, or release notes, based on Git commits between 2 revisions.
This can also be done with acommand line tool.
You can use this plugin either in apipeline or as apost-build action.
There is a complete running example available here:https://github.com/tomasbjerre/jenkins-configuration-as-code-sandbox
The plugin is compatible with thepipeline plugin and can be configured to support many use cases. You probably want to adjust it using theSnippet Generator.
ThegitChangelog step can return:
- Context - An object that contains all the information needed to create a changelog. Can be used to gather information from Git like committers, emails, issues and much more.
- String - A string that is a rendered changelog, ready to be published. Can be used to publish on build summary page, on a wiki, emailed and much more.
The template and context isdocumented here.
It can integrate with issue management systems to get titles of issues and links. You will probably want to avoid specifying credentials in plain text in your script. One way of doing that is using thecredentials binding plugin. The supported integrations are:
- GitLab
- GitHub
- Jira
You cancreate a file or maybe publish the changelog with:
You can filter out a subset of the commits by:
- Specifying specificfrom/toreferences/commits.
- Adding filter based on message.
- Adding filter based on commit time.
- Filter tags based on tag name.
- Filter commits based on commit time.
- Ignore commits that does not contain an issue.
You can make the changelog prettier by:
- Transforming tag name to something more readable.
- Changing date display format.
- Creating virtual tag, that contains all commits that does not belong to any other tag. This can be named something likeUnreleased.
- Creating virtual issue, that contains all commits that does not belong to any other issue.
- Remove issue from commit message. This can be named something likeWall of shame and list all committers that did not commit on an issue.
Check theSnippet Generator to see all features!
Here is an example that clones a repo, gathers all jiras and adds a link to jira in the description of the job. The context contains much more then this and isdocumented here.
node { deleteDir() sh""" git clone git@github.com:jenkinsci/git-changelog-plugin.git ."""def changelogContext= gitChangelogreturnType:'CONTEXT',from: [type:'REF',value:'git-changelog-1.50'],to: [type:'REF',value:'master'],jira: [issuePattern:'JENKINS-([0-9]+)\\b',password:'',server:'',username:'']Set<String> issueIdentifiers=newTreeSet<>() changelogContext.issues.each {issue->if (issue.name=='Jira') { issueIdentifiers.add(issue.issue) } } currentBuild.description="http://jira.com/issues/?jql=key%20in%20%28${issueIdentifiers.join(',')}%29"}Here is an example that clones a repo and publishes the changelog on job page. The template and context isdocumented here.
node { deleteDir() sh""" git clone git@github.com:jenkinsci/git-changelog-plugin.git ."""def changelogString= gitChangelogreturnType:'STRING',from: [type:'REF',value:'git-changelog-1.50'],to: [type:'REF',value:'master'],template:""" // Template is documented below!""" currentBuild.description= changelogString}By giving the plugin patterns, to match against commits, it can calculate next semantic version to use. This can be part of a release-pipeline, to automate version stepping. It will find the previous highest semantic Git tag and step it depending of matched patterns.
def nextVersion= getNextSemanticVersion()println"Next version:"+ nextVersion.toString();println" Major:"+ nextVersion.getMajor();println" Minor:"+ nextVersion.getMinor();println" Patch:"+ nextVersion.getPatch();
You can also specify custom regexp to match against commits:
def nextVersion= getNextSemanticVersionmajorPattern:'^[Bb]reaking.*',minorPattern:'^[Ff]eature.*',patchPattern:'^[Ff]ix.*'
The plugin can find the previous highest semantic Git tag and provide major/minor/path numbers as well as the tag.
def highestVersion= getHighestSemanticVersion()println"Highest version:"+ highestVersion.toString();println" Major:"+ highestVersion.getMajor();println" Minor:"+ highestVersion.getMinor();println" Patch:"+ highestVersion.getPatch();println" Git tag:"+ highestVersion.findTag().orElse("");
The template and context isdocumented here.
{{#tags}}##{{name}}{{#issues}}{{#hasIssue}}{{#hasLink}}###{{name}} [{{issue}}]({{link}}){{title}}{{#hasIssueType}} *{{issueType}}*{{/hasIssueType}}{{#hasLabels}}{{#labels}} *{{.}}*{{/labels}}{{/hasLabels}}{{/hasLink}}{{^hasLink}}###{{name}}{{issue}}{{title}}{{#hasIssueType}} *{{issueType}}*{{/hasIssueType}}{{#hasLabels}}{{#labels}} *{{.}}*{{/labels}}{{/hasLabels}}{{/hasLink}}{{/hasIssue}}{{^hasIssue}}###{{name}}{{/hasIssue}}{{#commits}}**{{{messageTitle}}}**{{#messageBodyItems}} *{{.}}{{/messageBodyItems}}[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}){{authorName}} *{{commitTime}}*{{/commits}}{{/issues}}{{/tags}}
If you are usingconventional commits:
<type>[optional scope]:<description>[optional body][optional footer(s)]
A changelog can be rendered (usingHelpers) like this:
# Changelog{{#tags}}{{#ifReleaseTag.}}## [{{name}}](https://gitservice/{{name}}) ({{tagDate .}}){{#ifContainsTypecommitstype='feat'}}### Features{{#commits}}{{#ifCommitType.type='feat'}} -{{#eachCommitScope.}} **{{.}}**{{/eachCommitScope}}{{{commitDescription .}}} ([{{hash}}](https://gitservice/commit/{{hashFull}})){{/ifCommitType}}{{/commits}}{{/ifContainsType}}{{#ifContainsTypecommitstype='fix'}}### Bug Fixes{{#commits}}{{#ifCommitType.type='fix'}} -{{#eachCommitScope.}} **{{.}}**{{/eachCommitScope}}{{{commitDescription .}}} ([{{hash}}](https://gitservice/commit/{{hashFull}})){{/ifCommitType}}{{/commits}}{{/ifContainsType}}{{/ifReleaseTag}}{{/tags}}
When the plugin is installed, it will add a new post build action in Jenkins job configuration.
- Git Changelog - Implements features fromgit-changelog-lib.
A couple of revisions are configured along with some other optional features. A editable template is available for the user to tweak.
The changelog is created from parsing Git and rendering the template with a context derived from the configured revisions.
This plugin can be built and started with maven and Jenkins' hpi plugin:
./run.shThe functionality is implemented ingit-changelog-lib. Pull requests are welcome!
About
Creates a changelog, or release notes, based on Git commits between 2 revisions.
Topics
Resources
License
Code of conduct
Contributing
Security policy
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Packages0
Uh oh!
There was an error while loading.Please reload this page.
Contributors9
Uh oh!
There was an error while loading.Please reload this page.

