Defining *project level* environemnt variables

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Defining *project level* environemnt variables

Sébastien Hinderer
Dear all,

I would like to be able to define an environment variable for Jenkins
but not at the job level, rather at the project level, so that it can be
shared between several different jobs.
Moreover I would like to be able to do this from the web interface,
because I do not have ssh access to the Jenkins server.

Is there a way to achieve this? I looked at the env injector plugin but
I believe it won't work for my use case.

Many thanks in advance for any hint,

Sébastien.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Defining *project level* environemnt variables

stephenconnolly
A folder property can contribute env vars.

My employer has this functionality I think in our folders-plus plugin... it’s not too hard to write, but sales blocked us open-sourcing it at the time (they’d probably be fine now, but I don’t have the energy to chase it)

Somebody may have already implemented it... if not, you could give it a shot and file a PR against the folder plugin to help us force the decision ;-)

On Sat 21 Oct 2017 at 15:24, Sébastien Hinderer <[hidden email]> wrote:
Dear all,

I would like to be able to define an environment variable for Jenkins
but not at the job level, rather at the project level, so that it can be
shared between several different jobs.
Moreover I would like to be able to do this from the web interface,
because I do not have ssh access to the Jenkins server.

Is there a way to achieve this? I looked at the env injector plugin but
I believe it won't work for my use case.

Many thanks in advance for any hint,

Sébastien.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyO5gDFQh8V9y0x2s%2Bvnjvy2qwzDMvFu7udXaD%3D%2B2-9LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Defining *project level* environemnt variables

Dan Tran
Here is the Jira https://issues.jenkins-ci.org/browse/JENKINS-42906 filed some time ago

On Saturday, October 21, 2017 at 7:46:40 AM UTC-7, Stephen Connolly wrote:
A folder property can contribute env vars.

My employer has this functionality I think in our folders-plus plugin... it’s not too hard to write, but sales blocked us open-sourcing it at the time (they’d probably be fine now, but I don’t have the energy to chase it)

Somebody may have already implemented it... if not, you could give it a shot and file a PR against the folder plugin to help us force the decision ;-)

On Sat 21 Oct 2017 at 15:24, Sébastien Hinderer <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="4SYfNiEhAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">Sebastien...@...> wrote:
Dear all,

I would like to be able to define an environment variable for Jenkins
but not at the job level, rather at the project level, so that it can be
shared between several different jobs.
Moreover I would like to be able to do this from the web interface,
because I do not have ssh access to the Jenkins server.

Is there a way to achieve this? I looked at the env injector plugin but
I believe it won't work for my use case.

Many thanks in advance for any hint,

Sébastien.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="4SYfNiEhAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/20171021132148.cabsf3ez3xksaffq%40pl-59055.rocqadm.inria.fr.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5d2241d2-ab23-4cb3-8962-39936a89e11d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Defining *project level* environemnt variables

Sébastien Hinderer
In reply to this post by stephenconnolly
Thanks a lot for your response, Stephen.
Not sure I'm brave enough to try to write something myself.
Just too bad it does not already exist but I guess we'll just do without
since it'd be a nice addition but not really mandatory.

Best wishes,

Sébastien.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/20171025163526.d4jptxm7lubfwqnm%40pl-59055.rocqadm.inria.fr.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Defining *project level* environemnt variables

Brian Ray
We use the Config File Provider plugin and the Pipeline Utilities Steps plugin in conjunction with folders to get around the JENKINS-42906 gap, in a Scripted Pipeline context.

This is actually nicer IMHO than the hidden env variables functionality, because you can use various flavors of configuration files, use an editor that understands your flavor(s) of choice, and then paste back into the UI.

In our case we're just using simple Java properties files something like the following.

  def props
  node
() {
    configFileProvider
( [ configFile( fileId: 'your-folder-cfg-file-id', variable: 'WHATEVER', replaceTokens: true ) ] ) {
      props
= readProperties( file: WHATEVER )
   
}
 
}
 
//now go do stuff with the props Map, even massaging for consumption by withEnv() ...

The ony downside is, I suppose, is the hacky nature of having the properties written down to the agent's workspace just to read them right back again and discard the file.

Brian

On Wednesday, October 25, 2017 at 11:39:09 AM UTC-7, Sébastien Hinderer wrote:
Thanks a lot for your response, Stephen.
Not sure I'm brave enough to try to write something myself.
Just too bad it does not already exist but I guess we'll just do without
since it'd be a nice addition but not really mandatory.

Best wishes,

Sébastien.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/f82c51af-34dc-4db8-b2bb-142177b10fbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Defining *project level* environemnt variables

Brian Ray
Forgot to write: We mitigate the hack by wrapping it up as a global library custom step.

On Tuesday, December 5, 2017 at 1:57:46 PM UTC-8, Brian Ray wrote:
We use the <a href="https://plugins.jenkins.io/config-file-provider" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplugins.jenkins.io%2Fconfig-file-provider\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNElvzcRRl7TSbqAoQ5qanB-3OcmSg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplugins.jenkins.io%2Fconfig-file-provider\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNElvzcRRl7TSbqAoQ5qanB-3OcmSg&#39;;return true;">Config File Provider plugin and the <a href="https://plugins.jenkins.io/pipeline-utility-steps" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplugins.jenkins.io%2Fpipeline-utility-steps\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGc_p3YF_DgOehCOWu4eMdbfx65vA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplugins.jenkins.io%2Fpipeline-utility-steps\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGc_p3YF_DgOehCOWu4eMdbfx65vA&#39;;return true;">Pipeline Utilities Steps plugin in conjunction with folders to get around the JENKINS-42906 gap, in a Scripted Pipeline context.

This is actually nicer IMHO than the hidden env variables functionality, because you can use various flavors of configuration files, use an editor that understands your flavor(s) of choice, and then paste back into the UI.

In our case we're just using simple Java properties files something like the following.

  def props
  node
() {
    configFileProvider
( [ configFile( fileId: 'your-folder-cfg-file-id', variable: 'WHATEVER', replaceTokens: true ) ] ) {
      props
= readProperties( file: WHATEVER )
   
}
 
}
 
//now go do stuff with the props Map, even massaging for consumption by withEnv() ...

The ony downside is, I suppose, is the hacky nature of having the properties written down to the agent's workspace just to read them right back again and discard the file.

Brian

On Wednesday, October 25, 2017 at 11:39:09 AM UTC-7, Sébastien Hinderer wrote:
Thanks a lot for your response, Stephen.
Not sure I'm brave enough to try to write something myself.
Just too bad it does not already exist but I guess we'll just do without
since it'd be a nice addition but not really mandatory.

Best wishes,

Sébastien.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/688fd93b-db7c-4f54-a4f0-90d9a24b781d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.