• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Can Jenkins + Groovy be used to set Environment Variables that are persistent across build jobs?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can Jenkins + Groovy be used to set Jenkins Environment Variables that are persistent across Jenkins build jobs, and hopefully, persistent across the Master server & the Slave servers in a build farm?

The StackOverFlow forum has a discussion of this topic, recommending use of the Jenkins plugin EnvInject, but no code samples are included, and the problem of how to make these Environment Variables persistent across servers was not addressed.

The StackOverFlow recommendation was to use the Jenkins plugin EnvInject, have the job export the value to a properties file (located in the Master), and have downstream jobs "read the value from the properties file at initialization, and expose it as environment variable to other build steps".

The Jenkins Environment Variables we would like to make persistent would be parameters used by Jenkins build jobs.

As a Groovy n00b I would greatly appreciate it if specific sample code could be provided on how to set Environment Variables that are persistent across Jenkins build jobs, and hopefully, persistent across the Master server & the Slave servers in a build farm. Our system is based on Windows, not UNIX.
 
Saloon Keeper
Posts: 25483
180
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The term "enviroment" in computer parlance normally is applied to ONE shell instance on ONE machine. At best, a shell's children might inherit a COPY of that environment. All other shells are building theirs from scratch, albeit often helped by common constructor scripts. A child shell can push environment settings up to its parent (the Unix "export" command), but the overall hierarchy prevails.

In Windows, the overall environment for a shell instance is actually built from 2 sets of constructors - the Global System properties and the per-instance properties, both maintained off the Control Panel System applet (or whatever Microsoft chooses to call it this week). Even if a Windows app doesn't actually launch in a command shell, there's still a shell attached to the process and that's where it gets its basic settings from.

So in order to replicate environment variable settings within a Windows machine, you'd have to push them to the same place that the Control Panel System GUI does (presumably the Registry). They would not reflect in running processes, only when new processes are created. Since each machine has its own System configuration, no other machine in the net could be affected. The only way to achieve that, short of adding some sort of Service to each machine whose sole purpose is to publish/subscribe to environment setting changes would be to edit a login script. Meaning that only when a machine first logged into the LAN would changes be seen.

I really wouldn't even use a properties file (presumably on a shared drive). Stuff like that is better kept in a database somewhere.

 
Alas, poor Yorick, he knew this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic