1

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.)

4
  • 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? Dec 19, 2019 at 12:07
  • 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)
    – Conrad B
    Dec 19, 2019 at 12:28
  • 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. Dec 19, 2019 at 12:47
  • @BruceBecker please post this comment as an answer
    – 030
    Dec 19, 2019 at 13:21

1 Answer 1

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
1
  • 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.
    – Conrad B
    Dec 22, 2019 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.