Thanks for the reply.
Basically, I’m trying to follow the principle whereby Gradle and its configuration is the source of truth for as many things as possible. For example, it’s certainly the source of truth for dependencies. So I want Gradle and its version property to be the source of truth for the version of the app we’re working on. At which point, I want to read the version value in Jenkins so that I can tag source when I do a release build. But reading that value seems either difficult or impossible.
For now, we have the following (not quite perfect) setup, which uses filesystem transfer similar to your suggestion.
gradle.properties has three values: versionMajor, versionMinor, versionBuild (suppose they are set to 1, 0, 10, respectively)
Gradle “version” property is calculated programmatically by concatenating these together, with an appended SNAPSHOT if we’re doing a snapshot build (1.0.10 or 1.0.10-SNAPSHOT)
The Jenkins release job is parameterized using the Extended Choice Parameter plugin to read versionMajor, versionMinor and versionBuild from gradle.properties (except it doesn’t; see below)
The Jenkins release job concatenates the values together to create the tag, which is applied using the Git Publisher
The problem is that gradle.properties is read by Jenkins before it fetches code from Git, and updates to gradle.properties are thus not always present when the job parameters are populated from that file. Typically, this means the versionBuild value lags by one increment. We’d tag build 1.0.10 with 1.0.9. So we prompt the Jenkins user for that value. If I could access Gradle’s version property directly, this problem would be solved.
Sorry for the long note, but I wasn’t sure how to be more succinct.