Build automation tool
Keyple uses Gradle.
Versioning rules
Keyple components are versioned according to Semantic Versioning 2.0.0 which is based on the three numbers X.Y.Z
-api
), the incrementation of Z
indicates only a documentation update.Continuous integration
Keyple continuous integration works with the Jenkins server of the Eclipse Foundation.
The build process uses the home-made gradle plugin Keyple Gradle available directly from the Maven Central Repository and whose sources are available on GitHub.
The CI automates the following tasks (defined in the Jenkinsfile
file):
- verify the validity of the version;
- verify the code formatting using Spotless;
- build the code;
- execute unit tests;
- sign and publish artifacts to Maven Central Repository;
- publish the javadoc to the corresponding GitHub Pages;
- publish the code quality report to SonarCloud.
Snapshot publication
A snapshot artifact (suffixed with -SNAPSHOT
) is automatically published after each commit on the main
branch, except in the case of a release (see Release publication).
gradle.properties
file must not have a -SNAPSHOT
suffix because the suffix is automatically added by the Keyple Gradle plugin.Release publication
A release artifact is automatically published if and only if the following two conditions are met:
- The commit is done on the
main
branch or on arelease-X.Y.Z
branch. - The commit message starts with
Release X.Y.Z
.
X.Y.Z
must be the version defined in the gradle.properties
file.Integration tests
Integration tests are defined in an independent GitHub repository: keyple-integration-java-test
Release procedure
- Create a branch dedicated to the current release.
- Check
gradle.properties
file:- Check the consistency of the version.
- Check
build.gradle.kts
file:- Use only released dependencies.
- Upgrade Keyple dependencies to their latest released versions.
- Update
CHANGELOG.md
file:- Verify the consistency of the
Unreleased
section. - Move content of
Unreleased
section to a new “release” section. - Update bottom links.
- Verify the consistency of the
- Build and test the component.
- Commit the modified files using the commit message
Release x.y.z
. - Push and create a pull request to merge the branch into
main
. - Await the success of the build by the CI.
- Squash and merge the pull request.
- Await the success of the build by the CI.
- Connect to Nexus Repository Manager of Eclipse Keyple and go to “Staging Repositories” page:
- Select the correct folder to Close & Release. It must contain the manifests, the JAR and all the others elements (sources, javadoc).
- Close the folder.
- Release the folder.
- The other unwanted folders could be dropped.
- Check the availability of the release on the Maven Repository. This step may take from 10 minutes to 2 hours.
- Create a release on GitHub:
- Set tag
x.y.z
- Set release name
x.y.z
- Set the content by copying/pasting the content of the current release description in the
CHANGELOG.md
file without the bottom links.
- Set tag
- Increment the version in the
gradle.properties
file and commit it to prepare the code for the next release (e.g.2.0.0 -> 2.0.1
). - Update this website:
- Update version in
params.yaml
file. - Update table content of
dependency-check.md
file. - Update others elements if needed (user guides, developer guides, etc…).
- Commit and push the modifications.
- Update version in