Giter VIP home page Giter VIP logo

gradle-github-changelog's Introduction

GitHub Changelog Gradle Plugin

Gradle plugin version Github Build License

Generates a changelog from GitHub issues and pull-requests.

This project is similar (in functionality and output) to the great GitHub Changelog Generator, but as a Gradle plugin.

When applied, the plugin automatically adds the generateChangelog task. This task calls GitHub to get information about your issues and pull requests, and generates a CHANGELOG.md file in your project's root folder.

How it works

The releases in the changelog are determined by the git tags of the repository. The date of the release is the date of the tag.

Closed issues are sorted into releases using their close date, but this behaviour can be overridden. More specifically, the following rules apply (by order of precedence):

  1. if the issue is forced into a tag via customTagByIssueNumber mapping, it is put under this tag
  2. if the issue has a milestone, and the title of that milestone matches a git tag, then the issue is put under this tag
  3. otherwise, the issue is put under the first tag that follows its close date

For example, all issues closed between the date of tag 1.0 and the date of the tag 1.1 are considered to be in release 1.1.

To see an example output, take a look at this project's CHANGELOG.md, which was generated with this plugin.

Issue sections

Within a given release, issues are sorted into sections based on their labels. Each issue label can be associated to at most one section, but a section can correspond to several labels. An issue is placed into a section according to the first of its labels that is associated to a section.

The default sections and the associated labels are:

  • Breaking changes: backwards-incompatible, breaking
  • New features: feature
  • Implemented enhancements: enhancement
  • Deprecations: deprecated, deprecation
  • Removals: removed, removal
  • Fixed bugs: bug
  • Upgraded dependencies: dependency, dependency-upgrade, dependencies

Release summary

If the list of issues itself is not enough, you can write a summary for a given release to describe the release further with full markdown capabilities.

To do so, you simply need to create a special issue:

  • with the label release-summary
  • with a milestone that has the same name as the release tag
  • with a body that contains the description of the release that you want to appear

Then close this issue and run the changelog generator.

Release notes for a single release

The changelog generation task also outputs a markdown file containing just the closed issues for the latest release (and the optional release summary), which is ideal for generating the latest release notes.

The default path to this file is $buildDir/reports/changelog/latest-release-body.md, and is customizable via the latestReleaseBodyFile extension property.

If you create a GitHub release from a GitHub Actions workflow, you can use this file as the body text of that release.

Usage

Applying the plugin

Add the following line to your plugins block (in the root project's build.gradle(.kts)):

plugins {
    id("org.hildan.github.changelog") version "<version>"
}

Where <version> is the desired version (see badge above without v prefix), e.g. 1.3.0.

Gradle compatibility:

Plugin Min Gradle Version
2.2.0 8.6
2.1.0 8.5
2.0.0 8.2
1.13.x 8.0
1.12.x 7.5
1.9.0 - 1.11.1 7.3
1.8.0 7.2
1.0.0 - 1.7.0 6.8
< 1.0.0 6.7

Minimal configuration

The minimal required configuration is your GitHub username.

It can be provided in 3 different ways depending on your needs:

  • the githubUser project property (add githubUser=user-or-org to gradle.properties)
  • the GITHUB_USER environment variable
  • the githubUser property of the changelog DSL (see below)

If you're using the project property or the environment variable, and stick with the defaults, you don't even need to define the changelog extension at all in your gradle file.

You can then simply run:

gradle generateChangelog

Complete configuration

Here is the extension DSL with all options and their default values:

changelog {
    githubUser = // [mandatory] project property "githubUser" or env variable "GITHUB_USER"
    githubToken = null // [optional] project property "githubToken" or env variable "GITHUB_TOKEN"
    githubRepository = rootProject.name
    
    title = "Change Log"
    showUnreleased = true
    unreleasedVersionTitle = "Unreleased"
    futureVersionTag = null
    sections = [] // no custom sections by default, but default sections are prepended
    defaultIssueSectionTitle = "Closed issues:"
    defaultIssueSectionOrder = 60
    defaultPrSectionTitle = "Merged pull requests:"
    defaultPrSectionOrder = 70
    includeLabels = []
    excludeLabels = [
        "doc",
        "documentation",
        "duplicate",
        "internal",
        "invalid",
        "no-changelog",
        "question",
        "wontfix"
    ]
    sinceTag = null
    skipTags = []
    skipTagsRegex = []
    releaseUrlTemplate = null // defaults to "https://github.com/$user/$repo/tree/%s"
    diffUrlTemplate = null // defaults to "https://github.com/$user/$repo/compare/%s...%s"
    releaseUrlTagTransform = { it }
    diffUrlTagTransform = { it }
    customTagByIssueNumber = [:]
    useMilestoneAsTag = true
    timezone = ZoneId.of("GMT")
    
    outputFile = file("${projectDir}/CHANGELOG.md")
    latestReleaseBodyFile = file("$buildDir/reports/changelog/latest-release-body.md")
}
  • githubUser: your GitHub username

  • githubToken: your personal access token. It is required to generate changelogs for private repositories, but optional for public repositories. Note that GitHub only allows 50 unauthenticated requests per hour. By providing an API token, you allow this plugin to log in and thus remove the limit, which makes it useful for public repositories too. If you don't have one yet, you may generate a personal token for your repo. You don't need to tick any permissions for the plugin to work on public repositories, but you need the repo permission if you want to generate changelog for private repositories ("full access to private repo").

  • githubRepository: the repository from which to get the issues to generate the change log.

  • title: the title of the change log

  • showUnreleased: if true, issues that were closed since the last tag will appear at the top of the change log. By default they will appear as "unreleased", unless a futureVersionTag is provided.

  • unreleasedVersionTitle: the title for the unreleased issues at the top of the change log. Ignored if futureVersionTag is provided.

  • futureVersionTag: if provided, and if showUnreleased is true, the unreleased issues will appear at the top of the change log under the provided tag. This allows to consider unreleased issues as part of an actual tag prior to actually creating the tag.

  • sections: custom sections to classify the issues within each release. The section definitions are used to build a label-to-section mapping. The custom sections should be provided as a list of SectionDefinitions, with a title and one or more associated issue labels. Issues are placed into a section according to the first of their labels that is associated to a section. The provided custom sections are appended to the default sections (they don't replace them). However, if a custom section is associated to a label that is usually handled by a default section, the custom section takes precedence. In fact, the last section defining a mapping for a given issue label wins, and default sections are listed first.

  • defaultIssueSectionTitle: section title for issues that are not classified in a specific section due to their labels

  • defaultIssueSectionOrder: section order for issues that are not classified in a specific section due to their labels

  • defaultPrSectionTitle: section title for pull-requests that are not classified in a specific section due to their labels

  • defaultPrSectionOrder: section order for pull-requests that are not classified in a specific section due to their labels

  • includeLabels: if not empty, only issues that have at least one of these labels can appear in the change log.

  • excludeLabels: issues that have at least one of these labels will not appear in the change log, even if they have labels that are present in includeLabels.

  • sinceTag: if provided, all prior tags will be excluded from the change log.

  • skipTags: some specific tags to exclude from the change log. The issues that are part of the excluded tags are also excluded from the change log. They are not reported under the next tag.

  • skipTagsRegex: tags matching one of these regexes are excluded from the change log.. The issues that are part of the excluded tags are also excluded from the change log. They are not reported under the next tag.

  • releaseUrlTemplate: custom template for the URL of releases to use in the hyperlink on the title. If present, a %s placeholder will be replaced by the tag of the release. By default, it points to the source code of the git repository at the given tag.

  • diffUrlTemplate: custom template for the URL to the full diff of the release. If present, 2 %s placeholders are replaced by the tag of the previous release and the current release, respectively. If you need to reverse the order, you may use %1$s for the "from" (previous) tag, and %2$s for the "to" (current) tag.

  • releaseUrlTagTransform: a function to transform the tag string before injection in the releaseUrlTemplate. By default, this is the identity function and doesn't change the tag. It may be handy to remove or add a "v" prefix for instance.

  • diffUrlTagTransform: a function to transform the tag strings before injection in the diffUrlTemplate. By default, this is the identity function and doesn't change the tags. It may be handy to remove or add a "v" prefix for instance.

  • customTagByIssueNumber: a mapping from issue numbers to tags. An issue may be incorrectly classified due to late closing date or other timing problems. If this is the case, use this map to override the tag to use for a particular issue.

  • useMilestoneAsTag: if true, issues associated to a milestone with a title that matches a tag will be associated to that tag, regardless of their close date.

  • timezone: the timezone used to convert the tags timestamps to local dates for releases (defaults to GMT).

  • outputFile: the file to write the change log to.

  • latestReleaseBodyFile: the desired output path to a markdown file containing the release notes for the latest release. This is useful when generating GitHub releases with an embedded changelog. By default, the path is $buildDir/reports/changelog/latest-release-body.md

gradle-github-changelog's People

Contributors

joffrey-bion avatar dependabot[bot] avatar gradle-update-robot avatar

Stargazers

Suresh avatar Peter avatar Alexi Bredus avatar Seal avatar Matthew Cain avatar Ned Twigg avatar Gonzalo Toledano avatar

Watchers

James Cloos avatar  avatar Seal avatar  avatar

Forkers

trebouys

gradle-github-changelog's Issues

Make timezone used for local dates more stable and/or configurable

Currently, the timezone used to display the local date for each version is the system's default.
This means that, depending on which machine generates the CHANGELOG, the release dates may be different.

The timezone should default to something more stable than the system default (GMT would be a more sensible default).

Also, it should be configurable so that people can use a different (but still stable) timezone.

Failed to run generateChangelog task

Running task on Gradle 6.7.1

  • What went wrong:
    Execution failed for task ':generateChangelog'.

kotlin.jvm.internal.FunctionReferenceImpl.(ILjava/lang/Object;Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;I)V

  • Exception is:
Caused by: java.lang.NoSuchMethodError: kotlin.jvm.internal.FunctionReferenceImpl.<init>(ILjava/lang/Object;Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;I)V

        at org.hildan.github.changelog.formatter.MarkdownFormatter$formatReleases$1.<init>(MarkdownFormatter.kt)
        at org.hildan.github.changelog.formatter.MarkdownFormatter.formatReleases(MarkdownFormatter.kt:22)
        at org.hildan.github.changelog.formatter.MarkdownFormatter.formatChangeLog(MarkdownFormatter.kt:17)
        at org.hildan.github.changelog.GitHubChangeLogGenerator.generate(GitHubChangeLogGenerator.kt:23)
        at org.hildan.github.changelog.plugin.GenerateChangelogTask.generate(GitHubChangelogPlugin.kt:33)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)

Release summary for 1.11.0

This release brings a new feature called "release summary".

The text you're reading is actually from a release summary itself.
It has been written as the body of a GitHub issue tagged with release-summary and associated to the milestone 1.11.0.

This is sufficient for it to be automatically picked up by the generator and placed here as description.

futureVersionTag

Hi - making sure i'm understanding this feature correctly, when generating the changelog I want to generate it to include the version I'm about to tag (but I'm deferring tagging until after the changelog is generated so to include it in the tag).

I know the version of the tag and set futureVersionTag to this value but it only generates the changelog until the previously tagged version. Is there a way to do what I want?

Publish to Gradle portal

Then we can add a badge like:

[![image](https://img.shields.io/maven-metadata/v/https/plugins.gradle.org/m2/org/hildan/gradle/org.hildan.github.changelog/maven-metadata.xml.svg?label=gradle)](https://plugins.gradle.org/plugin/org.hildan.github.changelog)

Allow using Milestones to determine association of issues with tags

Sometimes the issues closing date don't match with the tag date, and the association between an issue and the tag it is part of is broken.

It would be nice to allow a simple override mechanism by using milestones, just like github-changelog-generator:
https://github.com/github-changelog-generator/github-changelog-generator#features-and-advantages-of-this-project

Manually specify the version that fixed an issue (for cases when the issue's Closed date doesn't match) by giving the issue's milestone the same name as the tag of version

private repo support?

Hi - does this work with private repos? I'm just getting:

Could not find repository: https://api.github.com/repos/xxx/yyy

I do supply a Personal Access Token

generateChangelog task hangs

Reported by @yooksi.

the task execution hangs seemingly indefinitely - currently looking at 5 minutes execution time and counting up.

Any idea what might be causing this issue now?

Gradle version: 6.8.2
Plugin version: 1.3.0

Initial generation feature

The plugin should fetch issues from the github repository, split them in groups delimited by tags, and generate a CHANGELOG.md file with the list of issues for each version.

SkipTags support regular expression

Very Glad to find this Repo, After trying it, I found something need enhancement I think, If not support, I will need to list all of the tags that should not be show in Change Log like this

    skipTags = listOf(
        "v2.1-Alpha",
        "2.1-EAP",
        "EAP",
        "2.2.0.1-EAP",
        "2.2.1-EAP",
        "2.2.2-EAP",
        "2.2.3-EAP",
        "2.2.4-EAP",
        "V3.0-EAP",
        "V3.0-EAP-2",
        "v3.2.0-EAP",
        "3.3.0-EAP",
        "3.3.0-EAP-2",
        "3.4.0-EAP",
        "3.4.0-EAP-2",
        "3.5.0-EAP",
        "3.5.1-EAP",
        "3.6.0-EAP",
        "3.5.0-EAP-2",
        "3.7.0-EAP",
        "3.7.0-EAP-2",
        "3.7.0-EAP-3"
    )

It looks badly

I hope it could be set like this:

skipTags = listOf(".*EAP.*", ".*Alpha.*")

Release header mismatch

Release headers are not properly matched with release text content.

I've provided two changelogs in an attachment below to demonstrate this issue:

  • CHANGELOG1 was generated by github-changelog-generator.
  • CHANGELOG2 was generated by gradle-github-changelog.

As you can see every header has been moved up for one slot, also notice how v1.0.0 does not have a link to full changelog.

Attachment: mismatched-changelogs.zip

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.