How to set the upstream job build status based on downstream build status.

[Prem Subudhi]

Hi ,

Please guide me to fix the following issue.

Attempted following groove script to set the status but its throwing error .

upstreamJob = upstreamBuilds.keySet().iterator().next();

  lastUpstreamBuild = upstreamJob.getLastBuild();

  buildResult = manager.build.result;

  if(lastUpstreamBuild.getResult().isBetterThan(buildResult)) {

    manager.listener.logger.println("Adjusting build state of upstream job to build result of this job, being " + buildResult);

    lastUpstreamBuild.setResult(buildResult);

}

Error:

====

[workspace] $ /ccbuild/jenkins/tools/hudson.plugins.groovy.GroovyInstallation/Groovy-2.1.6/bin/groovy /ccbuild/jenkins/jobs/test1/workspace/hudson8022572837284303645.groovy

Caught: groovy.lang.MissingPropertyException: No such property: manager for class: hudson8022572837284303645

groovy.lang.MissingPropertyException: No such property: manager for class: hudson8022572837284303645

at hudson8022572837284303645.run(hudson8022572837284303645.groovy:2)

Build step 'Execute Groovy script' marked build as failure

Email was triggered for: Failure

Sending email for trigger: Failure

Thanks,

Prem

[James Nord]

You can't change the result of a build after the build has completed.

If you can explain what you are trying to accomplish at a higher level then we can probably let you know several ways in which you can accomplish this.

Regards

James

[Olli Sivonen]

Hello,

Sorry to reply to such an old post, but this is relevant to my current situation, and as I'm unable to find any other relevant discussion around this issue, I'm inclined to continue here instead of making a new topic.

I'm trying to achieve the following: Non-blocking downstream build changing the build result of an upstream build.

Previously I was able to use Groovy Postbuild to do this, since the assertation based limitation used in the core allowed such a hack. However, since core changed to use more restrictive checks, this method is now invalid.

I know I could achieve the update of build result by triggering a blocking downstream build and then changing the result of the upstream build based on the results of the other build. However, I don't want to have the upstream build eating up an executor while waiting for the downstream job to finish.

Why I'm trying to achieve this: We monitor some jobs externally and I would like to have as few jobs listed there as possible. Currently I'm building our software in one job and testing it in second, but I would only like to monitor the result of first job with the testing job affecting the result of the build job.

I realize this probably isn't the standard way of working with Jenkins and I could probably use some pointers in that area as well, but this is our current setup and problem. 

Do you happen to have any idea if I can achieve what I've described, or should I just change my perspective on the issue and modify the job design?

[Stephen Connolly]

Why not have the triggering job be a workflow? Workflows do not eat up an actual executor unless they are using a Node.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/269813be-17fb-477b-86f9-b23a78f7c8ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.