0

I have a pipeline set up that builds multiple project configurations. The order of building the confgurations doesn't matter, all that matters is whether all builds succeeded.

What I'd like to know is to which build configuration failed in the previous run of the pipeline (if the pipeline failed). The plan is to use this information to start the next build from that configuration, as it's likely the one which is going to fail again. I can already access previous pipeline build status using currentBuild.getPreviousBuild().result. Either of the following would work for me:

  1. Is it possible to store information between pipeline runs (full runs, not pipeline stages in the same run)?

or

  1. Is it possible to get the stage at which previous pipeline has failed on?
J_S
  • 2,985
  • 3
  • 15
  • 38

1 Answers1

4

You can persist the stage failed at the currentBuild.previousBuild.description.

As an alternative, you could archive a file an with whatever you need and acess it via currentBuild.previousBuild.rawBuild.artifactManager.root(). From there on, having a VirtualFile, you just would have to traverse the archived artifacts. Beware that this cleaner but long solution will (probably) require approving a good bunch of methods for the pipeline sandbox

PS: As stated by Jacek Ślimok, after setting an env variable with 

env.FAILING_BUILD="foo"

it is be available for the next build via

currentBuild.previousBuild.buildVariables.FAILING_BUILD
Javier Delgado
  • 171
  • 4
  • 1
    I'm accepting this as an answer as this would work too, although I've found an even better solution. There's a `getBuildVariables()` function that returns a map of environment variables set during previous build, e.g. I've set `env.FAILING_BUILD="foo"` in one build and it's available in the next build through `currentBuild.getPreviousBuild().getBuildVariables()?.FAILING_BUILD`. You may add this to your answer as another possibility if you wish. – J_S Jun 20 '18 at 17:08
  • buildVariables is documented to be related to a *downstream build*. In case it is available on any kind of job, its a leaner solution.WIll add it to the answer after testing it. – Javier Delgado Jun 20 '18 at 18:34