Re: Share environment variables between jobs
725 views
Skip to first unread message
GregHansen
Jul 31, 2014, 2:22:31 PM7/31/14
to jenkins...@googlegroups.com
Archiving the file only works if the parent job completes before triggering
the child job. At least in my case, I'm using the Parameterized Trigger
plugin as a build step, taking advantage of the built-in joining capability
that it gives, and then want to perform some action depending on the success
of all the child job (parent job fails if any of the child jobs fails).
So I don't have the luxury of archiving the properties file. Any way to pass
a pointer to it in the parent job's workspace? Would need to be a URI, to
include the node name, to handle the case of multiple builders.
An alternative would be able to say "start this job with this property file"
in the Parameterized Trigger plugin, where the Jenkins master would upload
the file, then send it to the child process.
It's things like this that make Jenkins awkward to use for complete
workflows, where a continuous environment between jobs makes sense.
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712982.html
Sent from the Jenkins users mailing list archive at Nabble.com.
the child job. At least in my case, I'm using the Parameterized Trigger
plugin as a build step, taking advantage of the built-in joining capability
that it gives, and then want to perform some action depending on the success
of all the child job (parent job fails if any of the child jobs fails).
So I don't have the luxury of archiving the properties file. Any way to pass
a pointer to it in the parent job's workspace? Would need to be a URI, to
include the node name, to handle the case of multiple builders.
An alternative would be able to say "start this job with this property file"
in the Parameterized Trigger plugin, where the Jenkins master would upload
the file, then send it to the child process.
It's things like this that make Jenkins awkward to use for complete
workflows, where a continuous environment between jobs makes sense.
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712982.html
Sent from the Jenkins users mailing list archive at Nabble.com.
Les Mikesell
Jul 31, 2014, 2:40:14 PM7/31/14
to jenkinsci-users
On Thu, Jul 31, 2014 at 1:22 PM, GregHansen <greg....@gigamon.com> wrote:
>
> It's things like this that make Jenkins awkward to use for complete
> workflows, where a continuous environment between jobs makes sense.
You could probably do it with the build-flow plugin, but given its
>
> It's things like this that make Jenkins awkward to use for complete
> workflows, where a continuous environment between jobs makes sense.
status and the fact that it requires extra jobs to manage things that
require workspaces like polling scms and collecting the artifacts, you
might be better off doing the equivalent operations in groovy.
--
Les Mikesell
lesmi...@gmail.com
GregHansen
Jul 31, 2014, 2:46:29 PM7/31/14
to jenkins...@googlegroups.com
A partial solution would be allow build steps to set the values of job-level
parameters, which could then be passed by the Parameterized Trigger plugin
to the child job. In my case, I would like to do this from within a shell
build step. Simple parameter-passing ....
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712984.html
parameters, which could then be passed by the Parameterized Trigger plugin
to the child job. In my case, I would like to do this from within a shell
build step. Simple parameter-passing ....
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712984.html
Les Mikesell
Jul 31, 2014, 2:50:43 PM7/31/14
to jenkinsci-users
On Thu, Jul 31, 2014 at 1:46 PM, GregHansen <greg....@gigamon.com> wrote:
> A partial solution would be allow build steps to set the values of job-level
> parameters, which could then be passed by the Parameterized Trigger plugin
> to the child job. In my case, I would like to do this from within a shell
> build step. Simple parameter-passing ....
>
Can't you do that in a groovy step?
> A partial solution would be allow build steps to set the values of job-level
> parameters, which could then be passed by the Parameterized Trigger plugin
> to the child job. In my case, I would like to do this from within a shell
> build step. Simple parameter-passing ....
>
--
Les Mikesell
lesmi...@gmail.com
Greg Hansen
Jul 31, 2014, 2:52:49 PM7/31/14
to jenkins...@googlegroups.com
I haven't had the time to learn both Groovy and the Jenkins context. Was looking for a plugin or a recipe to copy.
--
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.
For more options, visit https://groups.google.com/d/optout.
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.
For more options, visit https://groups.google.com/d/optout.
Les Mikesell
Jul 31, 2014, 2:57:49 PM7/31/14
to jenkinsci-users
On Thu, Jul 31, 2014 at 1:51 PM, Greg Hansen <greg....@gigamon.com> wrote:
> I haven't had the time to learn both Groovy and the Jenkins context. Was looking for a plugin or a recipe to copy.
>
Mostly the same here - I think you can do about anything in groovy but
> I haven't had the time to learn both Groovy and the Jenkins context. Was looking for a plugin or a recipe to copy.
>
you don't get the fill-in-the-form options.... But I think I'd
prefer some boilerplate code examples to a thousand discrete plugins
that you have to try to chain together and usually end up with some
operation missing.
--
Les Mikesell
lesmi...@gmail.com
GregHansen
Jul 31, 2014, 2:58:34 PM7/31/14
to jenkins...@googlegroups.com
Hmmm, the latest version of the Parameterized Trigger plugin (2.25) has this
(see the ***):
------
This plugin lets you trigger new builds when your build has completed, with
various ways of specifying parameters for the new build. You can add
multiple configurations: each has a list of projects to trigger, a condition
for when to trigger them (based on the result of the current build), and a
parameters section.
There is also a Parameterized Remote Trigger Plugin in case you want to
trigger a build on a different/remote Jenkins Master.
The parameters section can contain a combination of one or more of the
following:
a set of predefined properties
*** properties from a properties file read from the workspace of the
triggering build ***
the parameters of the current build
Subversion revision: makes sure the triggered projects are built with
the same revision(s) of the triggering build. You still have to make sure
those projects are actually configured to checkout the right Subversion
URLs.
Restrict matrix execution to a subset: allows you to specify the same
combination filter expression as you use in the matrix project configuration
and further restricts the subset of the downstream matrix builds to be run.
The parameter section is itself pluggable, and other plugins can contribute
other sources of parameters.
-----
I'll have to take a look at the part above where I added the stars. Might be
exactly what I need.
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712991.html
(see the ***):
------
This plugin lets you trigger new builds when your build has completed, with
various ways of specifying parameters for the new build. You can add
multiple configurations: each has a list of projects to trigger, a condition
for when to trigger them (based on the result of the current build), and a
parameters section.
There is also a Parameterized Remote Trigger Plugin in case you want to
trigger a build on a different/remote Jenkins Master.
The parameters section can contain a combination of one or more of the
following:
a set of predefined properties
*** properties from a properties file read from the workspace of the
triggering build ***
the parameters of the current build
Subversion revision: makes sure the triggered projects are built with
the same revision(s) of the triggering build. You still have to make sure
those projects are actually configured to checkout the right Subversion
URLs.
Restrict matrix execution to a subset: allows you to specify the same
combination filter expression as you use in the matrix project configuration
and further restricts the subset of the downstream matrix builds to be run.
The parameter section is itself pluggable, and other plugins can contribute
other sources of parameters.
-----
I'll have to take a look at the part above where I added the stars. Might be
exactly what I need.
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712991.html
GregHansen
Jul 31, 2014, 3:29:44 PM7/31/14
to jenkins...@googlegroups.com
Yes! I had to echo all the environment variables into the properties file
using the format:
echo "PARAM1=${PARAM1}" >> myprops.properties
(make sure your first echo has ">" instead of ">>", so the file gets
initialized)
The child build then had all those values!!!
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712995.html
using the format:
echo "PARAM1=${PARAM1}" >> myprops.properties
(make sure your first echo has ">" instead of ">>", so the file gets
initialized)
The child build then had all those values!!!
--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Share-environment-variables-between-jobs-tp2990985p4712995.html
Reply all
Reply to author
Forward
0 new messages