Answers: <p>Not sure if this would work for you, but what I do is store all of the build metadata into a <code>BuildInfo.json</code> file. You could just save it as an XML file like you said, but I found it easier to parse info with Groovy if it was a JSON file. Along with the most recent commit hash, we store most of the build information in this file, including the result, duration, user who kicked off the build, etc.</p>
  
  <p>One advantage of this approach is we're able to create other jobs that take action of already built products, such as for deployments. These jobs can just look for the presence of a <code>BuildInfo.json</code> file and take action based off the information contained within. Example:</p>
  
  <pre><code>import groovy.json.*
  
  def build_info = [
      'Product': 'MyApp',
      'Build Type': 'Full',
      'Build Name': currentBuild.displayName,
      'Version': '1.2.3.4',
      'Source Branch' : params.Branch,
  ]
  
  def json_output = readJSON text: groovy.json.JsonOutput.toJson(build_info)
  writeJSON file: "BuildInfo.json", json: json_output, pretty: 4
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-22T21:16:40.880Z
Answers: Thank you Argyle, a most excellent starter code snippet. The tip from Bruce has already helped too, and I had, suspected using a JSON file format would simplify farther. Hope to publish a small solution write-up after the holidays, writing my code in a way that I can publish most of it here verbatim. We need more Jenkins gurus like you guys online here.
Answers: Conrad B
Answers: CC BY-SA 4.0
Answers: 2019-12-20T20:05:52.717Z
Answers: 2019-12-20T20:05:52.717Z
Answers: Argyle
Body: <p>I have a job which I run with a boolean parameter called "BUILD_CLEAN=true", and it defaults to false. I can store this flag in the job ID <code>currentBuild.displayName</code> . Simple enough. But for my purposes I also want to save the commit hash(es) of that build as well, which starts becoming a silly place to store metadata. I'm probably not getting the terminology right, but here is my use case.</p>
  
  <p>My Pipeline declarative job builds a repo, a subrepo and all using shell, and archives the binary artifacts. The code is of mixed types, so Artifactory is not an option for part of this solution either. I want to save just the hashes someplace, to make it easy for subsequent builds made in the same day (24 hours) to inspect/list them, and trigger a separate job with the full list for that day. Do I save these hashes/values into an XML file per build? What is the best way to make extracting small pieces of data easy? <em>GOAL:</em> I'm attempting to implement a kind of generalized incremental build job, but am unable to use any of the plugins since I'm building for 5 different targets, some of them across nodes. In my specially marked build (nightly) every 24 hours, I'm .bz2 zipping the objects so I can restore them for any incremental. So it's this archive that I'm wanting to find, check the hashes and retrieve into my workspace.</p>
  
  <p>TAGS: Jenkins,pipeline,tags,incremental (I'm unable to define any tags due to the rep system.)</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-19T12:07:23.400Z
Comments: If you can generate a file with the content you want in it during a build, you could stash that across tasks, and then store them as artifacts? Would this be satisfactory?
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2019-12-19T12:28:28.367Z
Comments: I understand that stashes get deleted at end of a build, but yes, I am going to just archive the blob, but is that the most efficient or best practice way to simply store some metadata? (I've never used stashes, I assumed they are temporary)
Comments: Conrad B
Comments: CC BY-SA 4.0
Comments: 2019-12-19T12:47:11.103Z
Comments: that is correct, stashes are deleted, but you can unstash them before the end of the pipeline, and save them as artifacts. Then they are persisted in jenkins associated with the job. There is some consideration on the size of the stash too... If this is acceptable, it could be added as an answer.
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2019-12-19T13:21:18.513Z
Comments: @BruceBecker please post this comment as an answer
Comments: 030
Tags: <jenkins><jenkins-pipeline>
Title: Store data in Jenkins job description
UserDisplayName: Conrad B
ThreadText: # Store data in Jenkins job description
  
  (Asked by: username_0 on 2019-12-19)
  
  I have a job which I run with a boolean parameter called "BUILD\_CLEAN=true", and it defaults to false. I can store this flag in the job ID `currentBuild.displayName` . Simple enough. But for my purposes I also want to save the commit hash(es) of that build as well, which starts becoming a silly place to store metadata. I'm probably not getting the terminology right, but here is my use case.
  
  My Pipeline declarative job builds a repo, a subrepo and all using shell, and archives the binary artifacts. The code is of mixed types, so Artifactory is not an option for part of this solution either. I want to save just the hashes someplace, to make it easy for subsequent builds made in the same day (24 hours) to inspect/list them, and trigger a separate job with the full list for that day. Do I save these hashes/values into an XML file per build? What is the best way to make extracting small pieces of data easy? *GOAL:* I'm attempting to implement a kind of generalized incremental build job, but am unable to use any of the plugins since I'm building for 5 different targets, some of them across nodes. In my specially marked build (nightly) every 24 hours, I'm .bz2 zipping the objects so I can restore them for any incremental. So it's this archive that I'm wanting to find, check the hashes and retrieve into my workspace.
  
  TAGS: Jenkins,pipeline,tags,incremental (I'm unable to define any tags due to the rep system.)
  
  **Tags:** jenkins, jenkins-pipeline
  
  > **Comments:**
  > **username_1**: If you can generate a file with the content you want in it during a build, you could stash that across tasks, and then store them as artifacts? Would this be satisfactory?  
  > **username_0**: I understand that stashes get deleted at end of a build, but yes, I am going to just archive the blob, but is that the most efficient or best practice way to simply store some metadata? (I've never used stashes, I assumed they are temporary)  
  > **username_1**: that is correct, stashes are deleted, but you can unstash them before the end of the pipeline, and save them as artifacts. Then they are persisted in jenkins associated with the job. There is some consideration on the size of the stash too... If this is acceptable, it could be added as an answer.  
  > **username_2**: @username_1 please post this comment as an answer  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2019-12-20. Score: 1
  
  Not sure if this would work for you, but what I do is store all of the build metadata into a `BuildInfo.json` file. You could just save it as an XML file like you said, but I found it easier to parse info with Groovy if it was a JSON file. Along with the most recent commit hash, we store most of the build information in this file, including the result, duration, user who kicked off the build, etc.
  
  One advantage of this approach is we're able to create other jobs that take action of already built products, such as for deployments. These jobs can just look for the presence of a `BuildInfo.json` file and take action based off the information contained within. Example:
  
  ```
  import groovy.json.*
  
  def build_info = [
      'Product': 'MyApp',
      'Build Type': 'Full',
      'Build Name': currentBuild.displayName,
      'Version': '1.2.3.4',
      'Source Branch' : params.Branch,
  ]
  
  def json_output = readJSON text: groovy.json.JsonOutput.toJson(build_info)
  writeJSON file: "BuildInfo.json", json: json_output, pretty: 4
  
  ```
  
  > **Comments:**
  > **username_0**: Thank you username_3, a most excellent starter code snippet. The tip from username_1 has already helped too, and I had, suspected using a JSON file format would simplify farther. Hope to publish a small solution write-up after the holidays, writing my code in a way that I can publish most of it here verbatim. We need more Jenkins gurus like you guys online here.  
  
  ---
  
  