How do I get a custom Build Record Root Directory during a build?

[Ioannis Moutsatsos]

Due to space limitation I have assigned a custom Build Record Root Directory for my Jenkins server.

Now I need to create a data.path property assigned to the value of the archive folder of a particular JOB_NAME.

Before I assigned the custom Build Record Root Directory, I used to construct this property from the following components and environment variables:

data.path=JENKINS_HOME/JOB_NAME/builds/BUILD_ID/archive

This generated the default Jenkins data.path for build archives

After the change to the Build Record Root Directory, I do not seem to find any environment variable that exposes the custom Build Record Root Directory. 

Is there a way to get the Build Record Root Directory value during the build execution, so I can construct the data.path property correctly?

Thanks and best regards

Ioannis

[Daniel Beck]

There is no such environment variable. Accessing build records from file system during the build is essentially an anti-pattern, and will fail as soon as you use plugins like Compress Artifacts Plugin (or change the Build Record Root Directory option, as you're seeing). Try instead to use e.g. Copy Artifacts plugin, or the (REST) API of Jenkins -- it allows downloading archived artifacts.

If you're tied to your current approach, since you built the variable data.path from JENKINS_HOME, JOB_NAME etc. for you current setup, you could use the same variables to get to the new path -- you'll just have to adapt it to what you configured for Build Record Root Directory.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5154b296-5099-439c-932f-aedd579b9cb2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ioannis Moutsatsos]

Thanks Daniel! Yes, I agree in principle about the anti-pattern!

In our case however, builds from a variety of jobs write new metadata in a common properties file residing in one of a particular job build folder. Although reading and sharing data is well supported through the Jenkins API/REST, appending/updating is easier done using the local path to the file. A major improvement will come when we migrate to a database for maintaining these shared metadata files.

I ended up configuring a new global Jenkins property with the Build Record Root Directory that I can access through the build environment to dynamically create a local path. In the future, any changes to the Build Record Root Directory will be handled by a relatively simple update to this global property.

Best regards

Ioannis