Build process and continuous integration

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

Continuous integration

Keyple continuous integration is based on GitHub Actions and uses the reusable workflows defined in the dedicated Keyple Actions repository.

The CI automates the following tasks:

• 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 API documentation to the unified Keyple’s documentation GitHub pages;
• publish the code quality report to SonarCloud.

Snapshot publication

A new snapshot version (suffixed with -SNAPSHOT) is automatically built and published each time a commit is pushed to the main branch.

This allows developers to use the latest development state of Keyple without waiting for an official release. The published SNAPSHOT artifacts are available from the Eclipse Maven Snapshots repository.

Release publication

A new release version is automatically built and published whenever a GitHub release is created.

The generated artifact is based on the commit referenced by the newly created tag, ensuring full traceability between the source code and the published artifacts.

Integration tests

Integration tests are defined in an independent GitHub repository: keyple-integration-java-test

Release procedure

1. Create a branch dedicated to the current release.
2. Check gradle.properties file:
   • Check the consistency of the version (do not remove -SNAPSHOT suffix).
3. Check build.gradle.kts file:
   • Use only released dependencies.
   • Upgrade Keyple dependencies to their latest released versions.
4. Update CHANGELOG.md file:
   • Verify the consistency of the Unreleased section.
   • Move content of Unreleased section to a new “release” section.
   • Update bottom links.
5. Build and test the component locally.
6. Commit the modified files.
7. Push and create a pull request to merge the branch into main.
8. Await the success of the build by the CI on source branch.
9. Squash and merge the pull request.
10. Await the success of the snapshot publication by the CI on main branch.
11. 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.
12. Await the success of the release publication by the CI on main branch.
13. Check the availability of the release on the Maven Repository. This step may take from 10 minutes to 2 hours.
14. 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.