1. Maintainers

2. Contributing

Over the years, the plugin has tremendously grown in popularity. Contributions from the community are very welcome. Have a look at the contribution guidelines to get started.

3. Development

It is required to install and run Docker Community Edition (CE) on the machine running tests. Please refer to the installation manual for more information.

The following usage examples demonstrates running functional tests against the Docker instance:

$ ./gradlew functionalTest

4. Release Process

This section describes the release process designed and implemented for this project. Its main purpose is to explain to developers and maintainers how to prepare and release a new version of the binaries and the documentation.

4.1. Tools

The release process uses some external libraries and services described in detail below.

4.1.1. gradle-git

The gradle-git plugin is used to automatically determine the project version. org.ajoberstar.release-opinion is applied in the main build.gradle and configured in ReleasePlugin.kt. Please refer to the plugin documentation for more details.

4.1.2. gradle-git-publish

The gradle-git-publish Gradle plugin is used to publish the documentation to gh-pages branch. It is applied and configured in the DocumentationPlugin.kt file.

4.1.3. GitHub Actions

GitHub Actions service is used as our current CI/CD server. Build and deploy jobs are configured in the .github/workflows directory. Please refer its documentation for more details.

4.1.4. Gradle Plugin Portal

The Gradle Plugin Portal service is used to publish plugin versions. The Plugin Publishing Plugin uploads artifacts to a remote repository.

4.2. Workflow

The release process is automated to some extent. The following steps describe the workflow.

  1. Developer updates RELEASE_NOTES.md with new planned version.

  2. Developer commits all changes in local working copy.

  3. Developer triggers new version release using the following command: ./gradlew release -Prelease.stage=final -Prelease.scope=[SCOPE] where [SCOPE] can be one of major, minor or patch, and determines which part of the version string <major>.<minor>.<patch> will be incremented.

  4. Gradle executes a build on developer’s machine which calculates new version string, creates new tag with it and pushes to the origin.

  5. When Gradle build is finished, developer’s work is done and the rest of the release process is automated.

  6. After push to the origin, GitHub Actions detects new tag and triggers a build.

  7. Executes a release stage if the commit also points to a Git tag.

  8. This stage assembles plugin binaries (with new version) and uploads them to Bintray (credentials are stored as encrypted secrets in GitHub). Furthermore, the API docs and the user guide are published to gh-pages branch (the access token is stored as secure variable).