GradleReleaseBOF
From SPA Wiki
Releasing Using Gradle
BOF session on Monday 30th June at 5:30pm
The Problem
- Legacy software that uses a custom set of Ant scripts to build multiple applications from a dozen or so modules each, some shared
- Build system uses a system of "manifests" to identify versions of modules and builds EVERYTHING from source (in CVS)
- Builds take a long time; no CI; inconsistencies creep in between module versions included in different applications; third-party libraries not up to date
- Successfully introduced Gradle as a substitute for Ant; dependency and version management now much cleaner
- Started developing some new modules and storing them in git instead of CVS (the intention is eventually to move from CVS to git for all)
- BUT: cutting a release is now a laborious process, as we have to trace all snapshot dependencies first and freeze them
Approaches Suggested during the BOF
- Investigate use of Ivy to manage dependencies
- Assemblertasks.gradle contains a dependencies block that amounts to a manifest - extract this to a new file e.g. manifest.gradle
- Create a script that generates the manifest automatically from latest versions of each dependency
- Create a script that creates a release branch
- Create a script that visits each module in the manifest and if its latest version is a snapshot, creates the corresponding release version on the release branch
- Each module needs to be built on the release branch at a fixed version
- The artifact version can be fed into each build.gradle using a parameter or by running a script to extract the latest tag from module.info - this obviates the need to modify build.gradle to move from snapshot to release to next snapshot version