Table of contents:
Since all the korlibs share its build process, there is a gradle plugin with all that common code:
It is published at the main plugins.gradle repository and bintray:
This plugin configures all the targets in a known way and provides several tasks:
./gradlew releaseVersion -PnextReleaseVersion=x.y.z- releases a specific version
./gradlew releaseQuickVersion- releases the snapshot and increments the patch version
These commands, will update the
gradle.properties version, will make a commit and a push
and will do the same for a SNAPSHOT version.
So there is only one commit with a non-snapshot version in the repository.
This should be performed in the master branch from a contributor.
The plugin provides a way
Artifact publishing is done via travis.
Each travis repository is configured with two private envs:
BINTRAY_KEY that are used to publish to bintray.
Korlibs use travis build stages to first test the repository, then upload the artifacts to bintray when on the master branch and non SNAPSHOT versions, and then publish them.
You can check an example checking a .travis.yml.
This stage includes three jobs, one per operating system and check the libraries in different operating systems and configurations:
This stage upload all the artifacts to bintray.
It only happens on the master branch, and only when the version@
gradle.properties does not end by
Since you cannot use mac to generate windows artifacts, it has:
This stage just calls the publish API that will make all the uploaded artifacts from the previous stage available to everyone, only if everything went fine.
./gradlew actuallyPublishBintrayprovided by the