Cool. Thanks for sharing.
I just found another way that also seems to work well - sharing it in case
it helps someone else... sorry if it's a bit verbose.
When I was trying the EnvInject plugin, I was setting the EnvInject
properties file like this: "mailing_list = buildf...@mydomain.com" in my
shell-script build step, upon a certain condition. In the next build step
("Inject Environment Variables"), I set the path to the EnvInject
properties file so that the environment variables would be exported. Then
in the post-build step (email-ext plugin), I was setting "recipients" to
the $mailing_list environment variable. This setup worked when the build
step passed but didn't work when the build step failed (because the
EnvInject build step was not executed, as noted earlier).
In the new approach, I am simply echoing a message in my shell script
build-step, upon a certain condition:
echo "Setting new mailing list for alarms on build failure"
Then using the Groovy PostBuild
plugin<https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin>,
I added a Groovy PostBuild step that contains the following code:
import hudson.model.*
// based on http://stackoverflow.com/a/12721531/376240 : how to export
env variables in groovy script in jenkins
if(manager.logContains(".*Setting new mailing list.*"))
{
def pa = new ParametersAction([
new StringParameterValue("mailing_list", "buildf...@mydomain.com")
])
// add the env variable to current job
Thread.currentThread().executable.addAction(pa)
}
What this Groovy script is doing is searching for the "Setting new mailing
list for alarms on build failure" in the build log. When found, it exports
the "mailing_list" environment variable that is used by the next post-build
step (the email-ext plugin whose "recipients" is set to $mailing_list).
This is quite hacky but is working fine for me. It's a shame that both
solutions/workarounds in this thread involve jumping through so many hoops
in order to get a simple (and probably quite common) thing done.
Thanks,
Ambar
On Monday, 6 January 2014 12:12:48 UTC+5:30, Dirk Heinrichs wrote:
>
> Am 06.01.2014 00:59, schrieb ambar s:
>
> Did you find a solution or workaround to this problem?
>
>
> Yes. You shouldn't let the build fail. Instead, each build step should set
> a status variable which indicates wether it has failed or not. Then, add a
> final env-inject (if needed), followed by another build step, which
> examinates the status variables and let the build fail depending on their
> values.
>
> HTH...
>
> Dirk
> --
>
> *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions
> *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach
> *Tel*: +49 2226 1596666 (Ansage) 1149
> *Email*: d...@recommind.com <javascript:>
> *Skype*: dirk.heinrichs.recommind
> www.recommind.com
>
--
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-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
