How to make AbstractBuild getEnvironment work in the presence of MultiJobs?

[William Roberts]

Hi,

I have publisher and SCM plugins which use build.getEnvironment() to get the
build environment variables, and later use EnvVars expand() to substitute
environment variables in various strings.

Here's a code snippet:

    public boolean checkout(AbstractBuild<?, ?> build, Launcher launcher,
FilePath workspace, BuildListener listener, File changelogFile) throws
IOException, InterruptedException {

       final EnvVars envVars = build.getEnvironment(listener)

;

       if (effectiveLabel != null) {
             effectiveLabel = fixEmpty(envVars.expand(effectiveLabel));
       }
       ...

This works fine in a parameterised job if I launch it directly, but if the
job is invoked from a MultiJob which passes in parameters, the substitution
uses the default parameter values from the job, not the values supplied from
the controlling MultiJob.

I'm guessing this is related to having multiple blocks of parameters - I can
see two "Parameters" links in the status page for the completed job.

What's the recommended way of getting the effective environment, as seen by
the build steps?

Thanks,
William

[cjo]

Your code looks correct for the case you want, and I would check the parameter issue first as that is probably the cause of your issues.

1. How are parameters passed from the Matrix job? is this using the Parameterized trigger plugin?

If not how is the downstream job being triggered from the matrix job?

2. Check the jobs build.xml (<$JENKINSHOME>/jobs/builds/<build_id>/build.xml) to see why there are two Parameters items shown, this should list the two ParameterActions and list the parameters that they are providing, and potentially provide some information on where they are coming from.

Duplicate ParameterActions might be caused by plugins adding them during build time, which then breaks things and then potentially removing them again rather than creating their own Enviroment Contributing Action.

3. Check that the parameters are correctly added to the environment during a build step, by adding a simple shell build script that outputs the environment and check to see if the correct values are there.

Hope this helps 

Chris.

[William Roberts]

The job is triggered by a phase in a Multijob (Jenkins Multijob plugin v1.7), with the default "current job parameters" setting.

This produces a build.xml with two ParametersAction elements: the first is from the Multijob build which triggered this job, the second is the default parameters for the current job.

The buildstep sees the first block, but the publisher sees the second block.

If I use a parameterized trigger to launch a third job, that one has only one set of parameters, and works as expected. It also managed to capture the parameters as seen by the buildstep, so it has the value I put into the original Multijob build page.

Does this imply that the problem is in the Multijob plugin?

William

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[cjo]

Just looked at the case you mentioned and can reproduce it, from what I can see in the Multijob plugin, it creates both of the Parameter actions itself, and does not seem to combine them.

and then due to the way that the Enviroment variables are provided to the different items via build.getBuildVariables() (added to launcher) and via build.getEnviroment() causes you to only see one of the sets of the values as they override eachother.

at [1] in the code it creates the default parameters from the job to be triggered. not added to the actions list.

At [2] it gets the parameters from the build that is triggering it and merges it with any actions already added to the list. if none already exist it creates a new one and adds it. 

At [3] It gets additional actions from the configs (Add Parameters items) and merges/adds these as needed

At [4] it then adds the default parameters to the action list created at [1] which I think is the error causing the duplicate ParametersAction.

These two lines should be moved to [1] and added to the action list first, and all other code will merge with these default Parameters overriding as necessary.

Please create a Issue on that plugin reporting this.

I have created an Issue for this 

https://issues.jenkins-ci.org/browse/JENKINS-16715

And will create a quick pull request that should fix it.

Chris

[1] https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/src/main/java/com/tikal/jenkins/plugins/multijob/PhaseJobsConfig.java#L292

[2] https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/src/main/java/com/tikal/jenkins/plugins/multijob/PhaseJobsConfig.java#L297

[3] https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/src/main/java/com/tikal/jenkins/plugins/multijob/PhaseJobsConfig.java#L312

[4] https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/src/main/java/com/tikal/jenkins/plugins/multijob/PhaseJobsConfig.java#L321

[William Roberts]

I have created an Issue for this 

https://issues.jenkins-ci.org/browse/JENKINS-16715

And will create a quick pull request that should fix it

Thanks Chris - that's amazing turnaround!

Unfortunately it looks as though the Tikal guys have lost interest and don't seem to be responding to email or monitoring the issues raised on their plugin. What's the usual protocol for making a new release in such cases?

William