Kotlin-based Custom Gradle Plugin for Build Automation

Project roadmap

1. 01

   Set up the plugin project

   ~1.5h

   Create a Gradle project using the Kotlin DSL with the java-gradle-plugin and kotlin-jvm plugins. Declare your plugin in the gradlePlugin block with an id (such as com.example.release) and an implementation class that implements Plugin<Project>. Its apply method registers a placeholder task. Done when: ./gradlew build succeeds and a test project can apply the plugin by id.

2. 02

   Read commits and tags

   ~2h

   Write a GitHistory class that finds the latest tag matching v<major>.<minor>.<patch> and lists the commit messages since that tag, running git commands with ProcessBuilder (or using JGit). With no tags yet, start from 0.0.0 and use all commits. Report a clear error when the directory isn't a Git repository. Done when: in a test repository, GitHistory returns the last version and the new commits.

3. 03

   Calculate the next version

   ~2h

   Parse each message as a Conventional Commit: type, optional scope, optional ! and description. A BREAKING CHANGE footer or ! means major, feat means minor, and fix or perf means patch; other types don't change the version. Before 1.0.0, treat breaking changes as minor. Put this logic in plain Kotlin classes, separate from Gradle. Done when: unit tests cover each bump rule and pre-1.0 behavior.

4. 04

   Generate the changelog

   ~2h

   Generate a Markdown entry for the new version with today's date and sections for Breaking changes, Features and Bug fixes, each listing commit descriptions with their scope in bold. Prepend it to CHANGELOG.md, creating the file if it doesn't exist, and skip commits that don't match the format. Done when: running it in a test repository adds a correctly formatted entry at the top of CHANGELOG.md.

5. 05

   Add the DSL extension and tasks

   ~2h

   Create a ReleaseExtension with Property and ListProperty fields: changelogFile, versionFile (such as gradle.properties), tagPrefix and the list of commit types to include. Register tasks nextVersion (prints the version), updateChangelog and bumpVersion (writes the version file), wiring them to the extension with lazy providers so they work with Gradle's configuration cache. Done when: a project can configure release { ... } in build.gradle.kts and run the three tasks.

6. 06

   Test with Gradle TestKit

   ~2.5h

   Write functional tests with GradleRunner that create a temporary project with a Git repository and example commits, apply the plugin, and run the tasks. Check the calculated version, the changelog content and the updated version file. Also run once with --configuration-cache. Done when: ./gradlew test passes, including the functional tests.

7. 07

   Publish the plugin

   ~1h

   Add the maven-publish plugin and publish to your local Maven repository with ./gradlew publishToMavenLocal. Write a README explaining how to apply and configure the plugin, with a full example. Done when: a separate sample project applies the plugin from mavenLocal() and runs its tasks successfully.

Resources

• DocsGradle: developing custom plugins
• DocsGradle: lazy configuration
• DocsGradle TestKit
• DocsConventional Commits specification
• DocsSemantic Versioning