(This is perhaps more a Jenkins question, but does seem relevant for this forum.)
I would like to access Gradle properties in my Jenkins job configuration. The specific case is that I would like to use Gradle’s “version” property when constructing a tag for a release build via Git Publisher.
I know Gradle can access environment variables set by Jenkins, but I have not found a way for Jenkins to access Gradle properties. I tried setting a java system property and accessing it with ${MY_PROP} syntax in Jenkins, but that did not work.
Well, gradle has an advantage in reading properties set by Jenkins, because Jenkins initiates the Gradle build. A way that I have used to pass properties back up to a CI server is dumping specific properties out to a file and having the CI server parse it.
I’m not familiar enough with Jenkins to know how that would work.
Do you have more details on your use case? That might help the community think of options.
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.
If Jenkins needs to know the version for tagging purposes, and there is no way to make Jenkins read gradle.properties after updating the Git repository, then I see two options:
Keep the version in Jenkins, and pass it down to Gradle * Let Gradle tag sources, at which point Jenkins might no longer need to know the version
Yes, the EnvInject plugin works perfectly. I didn’t know about it until your note. It fixes both issues I had (only the first of which I posted): * I needed to read gradle.properties after the pull from Git * I wanted to specify a relative instead of absolute path to gradle.properties on the build machine
The gradle.properties file is also controversial to put into version control. While this allows a team to share certain build settings, it makes it harder to have individual settings. I would recommend to use gradle.properties only for the “official” properties listed here http://www.gradle.org/docs/current/userguide/build_environment.html or for settings that are very similar in nature.