Passing Generated Value to Downstream Job

Question

I'm struggling to figure out a way to populate a parameter for a downstream, freestyle project based on a value generated during my pipeline run.

A simplified example would probably best serve to illustrate the issue:

//other stuff...
stage('Environment Creation') {

  steps {
    dir(path: "${MY_DIR}") { 
       powershell '''
          $generatedProps = New-Instance @instancePropsSplat

          $generatedProps | Export-Clixml -Depth 99 -Path .\\props.xml

       '''
       stash includes: 'props.xml', name: 'props'
    }
  }
}
//...later
stage('Cleanup') {
   unstash props
   // either pass props.xml 
   build job: 'EnvironmentCleanup', wait: false, parameters: [file: ???]
   // or i could read the xml and then pass as a string
   powershell '''
      $props = Import-Clixml -Path props.xml
      # how to get this out of this powershell script???
   '''
}

I create some resources in one stage, and then in a subsequent stage I want to kick off a job using those resources as a parameter. I can modify the downstream job however I want, but I am struggling to figure out how to do this.

Things I've tried:

File Parameter (just unstashing and passing through)
- Apparently do not work with pipelines

Potential Paths:

EnvInject: may not be safe to use and apparently doesn't work with pipelines?
Defining a "global" variable like here, but I'm not sure how powershell changes that

So, what's the best way of accomplishing this? I have a value that is generated in one stage of a pipeline, and I then need to pass that value (or a file containing that value) as a parameter to a downstream job.

You want a Powershell object available to another downstream Powershell context? What doesn't work about using `Export/Import-Clixml`? — codewario, Aug 13 '18 at 14:38
@BendertheGreatest I am wanting a powershell object, or just a string value contained within that object available as a parameter when kicking off another build — Sven Grosen, Aug 13 '18 at 14:42
Export-Clixml exports an Xml representation of a powershell object, and can be imported in another powershell session. I'm failing to understand why this doesn't work for you. — codewario, Aug 13 '18 at 18:44
@BendertheGreatest because I need it accessible outside of a powershell session: I need to pass it to a `build` call, I've figured out a different way of getting this done and I'll post that solution as an answer of my own — Sven Grosen, Aug 13 '18 at 20:48
Ahhhh gotcha. I assumed you wanted it further on in a Powershell context. I would solve this by either parsing the XML object from `Export-Clixml` or serialize whatever data you want to a file that can be read later. Alternatively, you could leverage environment variables to store info to be read later if the information isn't sensitive in nature. — codewario, Aug 14 '18 at 17:01

score 0 · Accepted Answer · answered Aug 13 '18 at 20:53

So here's the approach I've found that works for me.

In my stage that depends on the file created in a previous stage, I am doing the following:

stage ("Environment Cleanup') {
  unstash props
  archiveArtifacts "props.xml"

  build job: 'EnvironmentCleanup', parameters: [string(name: "PROJECT", value: "${JOB_NAME}")], wait: false
}

Then in my dependent job (freestyle), I copy the "props.xml" file from the triggering build and using the job name passed in as a parameter, then execute my powershell to deserialize the xml to an object, and then read the properties I need.

The last, and most confusing, part I was missing was in the options for my triggering pipeline project I needed to grant copy permission to the downstream job:

options {
  copyArtifactPermission('EnvironmentCleanup') // or just '*' if you want
}

This now works like a charm and I will be able to use it across my pipelines that follow this same workflow.

Passing Generated Value to Downstream Job

1 Answers1