EnvInject for post-build actions when build step fails

1,041 views
Skip to first unread message

Dirk Heinrichs

unread,
Sep 12, 2013, 4:38:36 AM9/12/13
to jenkins...@googlegroups.com
Hi,

I need some environment variables produced by a build step in a
post-build action (namely: EmailExt). Therefor, the build step writes a
properties file and a second build step (EnvInject) injects the
variables from that properties file. Works fine as long as the first
build step doesn't fail.

In case of failure, the EnvInject build step isn't executed anymore, so
that the environment variables are not available in the post-build
action. How do I propagate environment variables to post-build actions
in case of a failed build?

Thanks...

Dirk
--

*Dirk Heinrichs*, Senior Systems Engineer, Infrastructure
*Recommind GmbH*, Von-Liebig-Straᅵe 1, 53359 Rheinbach
*Tel*: +49 2226 1596666 1149
*Email*: d...@recommind.com <mailto:d...@recommind.com>
*Skype*: dirk.heinrichs.recommind
www.recommind.com <http://www.recommind.com>


http://www.recommind.com

ambar s

unread,
Jan 5, 2014, 6:59:07 PM1/5/14
to jenkins...@googlegroups.com, d...@recommind.com
Hi Dirk,
I am facing the exact same problem. The EnvInject step doesn't seem to run when the build fails - and therefore I can't get the injected variables for my ext-email step.

Did you find a solution or workaround to this problem?


Thanks,
Ambar

Dirk Heinrichs

unread,
Jan 6, 2014, 1:42:48 AM1/6/14
to jenkins...@googlegroups.com
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
Skype: dirk.heinrichs.recommind
www.recommind.com

ambar s

unread,
Jan 6, 2014, 11:44:10 AM1/6/14
to jenkins...@googlegroups.com, d...@recommind.com
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 = buil...@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, 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", "buil...@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
Reply all
Reply to author
Forward
0 new messages