1

What's I'm trying to solve

I've a job on Jenkins to trigger a shell script, which generates an artifact and uploads to NFS. I would like to add a flow for QA to visit Jenkins to promote the build as a release build after the build is verified. At the moment, the test is not automated so the trigger of promotion is manual. What the promotion does is moving the artifact on NFS to a different location. I'm thinking to either use Ansible or shell script to archive this.

What's the problem

The problem is that when the promotion is triggered, I need to know the location of the build on NFS, SVN#, etc for each specific build# in this Jenkins job. I'm wondering if there's existing plugin or solutions for this.

What I have in mind

  1. As part of the build steps, gather these info and write it to a flat file / relational DB so that the build #, Build Path, revision # and svn diff are stored in the DB. When the promotion is trigger, a script will read from DB and perform the promotion.

I think reading and writing to a DB is doable, but seems a bit overkill to me. I'm just wondering if i'm missing something here. I'm curious if Jenkins has built-in plugins for similar use case.

Thanks!

Kevin Yu
  • 85
  • 1
  • 11

1 Answers1

1

You are on correct path. Read this answer: How to promote a specific build number from another job in Jenkins?

In your build job, save all the information you need to a properties file: 

var1=blah  
var2=lalala

Archive this file at the end of the build process (archiving is standard post-build step)

When your promotion runs, you need to use PROMOTED_NUMBER parameter to specify which build to act on. Then use Copy Artifacts plugin, to pull that previously saved properties file to the workspace of the promotion (read the linked answer). Once copied, you can load the properties file as environment variables with EnvInject plugin, or use it in shell/ansible as is.

Edit:
You don't need 2 jobs for this, as described in linked answer. But remember that promotion process runs as separate process but uses the same workspace as the main job, so to avoid conflicts within workspace, make a separate folder just for the promotion process and do all your promotion work there.

Community
  • 1
  • 1
Slav
  • 27,057
  • 11
  • 80
  • 104
  • Thanks Slav. I am able to solve my problem based on your solution. I totally agree to do promotion in a separate folder. Right now I'm considering the scenario when multiple users try to promote different builds. I assume I would have make the folder unique in a way so that no race condition is introduced. – Kevin Yu Nov 13 '15 at 00:19
  • I don't think you can run multiple promotion processes of the same job at the same time, but if it is, you can always use `$PROMOTED_NUMBER` appended to a workspace name to make it unique. Just make sure you have some kind of cleanup, otherwise you will be cluttered with these unique folders that never get deleted – Slav Nov 13 '15 at 15:29
  • Yep, I used job name&PROMOTED _NUMBER to make it unique. Right now each of the artifacts in the folder is only 100B so I might keep them there for reference. Still not sure if I need those info later or not . – Kevin Yu Nov 13 '15 at 17:37