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.
-
Developer updates
RELEASE_NOTES.md
with new planned version. -
Developer commits all changes in local working copy.
-
Developer triggers new version release using the following command:
./gradlew release -Prelease.stage=final -Prelease.scope=[SCOPE]
where[SCOPE]
can be one ofmajor
,minor
orpatch
, and determines which part of the version string<major>.<minor>.<patch>
will be incremented. -
Gradle executes a build on developer’s machine which calculates new version string, creates new tag with it and pushes to the
origin
. -
When Gradle build is finished, developer’s work is done and the rest of the release process is automated.
-
After push to the
origin
, GitHub Actions detects new tag and triggers a build. -
Executes a release stage if the commit also points to a Git tag.
-
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).