Reading Gradle properties in Jenkins

(Dan Stine) #1

(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.

Is this possible?

(Andrew Oberstar) #2

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.

(Dan Stine) #3

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.

  1. has three values: versionMajor, versionMinor, versionBuild (suppose they are set to 1, 0, 10, respectively)

  2. 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)

  3. The Jenkins release job is parameterized using the Extended Choice Parameter plugin to read versionMajor, versionMinor and versionBuild from (except it doesn’t; see below)

  4. The Jenkins release job concatenates the values together to create the tag, which is applied using the Git Publisher

The problem is that is read by Jenkins before it fetches code from Git, and updates to 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.

(Peter Niederwieser) #4

If Jenkins needs to know the version for tagging purposes, and there is no way to make Jenkins read 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

(Stefan Wolf) #5

Can’t you just use the EnvInject Plugin to inject the property from the property file as build environment after the SCM checkout?

(Dan Stine) #6

Oh, frabjous day!!

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 after the pull from Git * I wanted to specify a relative instead of absolute path to on the build machine

Thank you, Stefan.

(Thibault Kruse) #7

The 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 only for the “official” properties listed here or for settings that are very similar in nature.