I am using all kind of parameters like "Active Choice Parameter", "Active Choice Reactive Parameter", "Active Choice Reactive Reference Parameter" that have a lot of Groovy code within them. My problem is that now I need to audit changes so I can link regression to code commits. I don't see an option to load the code from a SCM, how do I version this?
2 Answers
As far as I can tell, there is no native functionality in Active Choice Parameters to load the Active Choice code from SCM. There are a couple ways to build this functionality yourself, however they're both clunky solutions that can be difficult to debug. (Unfortunately I can't copy any example code from my work right now because I'm at home on my personal computer. Remind me after the weekend is over and I might be able to find some example code snippets to go along with these suggestions.)
Your Active Choice scripts can clone a repo, read in a file, and eval it. This is made quite difficult by the fact that Active Choice scripts don't have any access to the Pipeline DSL, so you can't use any of the steps you would normally use in Pipeline code to clone a repo like
scm
orgit
orwithCredentials
. There are also many other considerations you'll need to take into account which you normally can ignore in Pipeline code, like ensuring that you run the clone inside a temporary directory and so on. Ultimately I found this too difficult to do so I have been using the second solution instead:You can write a separate "meta" job that updates the parameters of your actual job and injects the Active Choice groovy scripts into its parameter configuration. I set this job to run on a hook on the repo which contains my Active Choice scripts, so every time I push to that repo, it updates the Active Choice groovy scripts. This does rely quite heavily on the Jenkins Java API (which is available in Active Choice groovy scripts), so you'll need to get familiar with the ins and outs of that API. That API can be quite a maze, especially for Pipeline-related endpoints (since Pipeline source code is heavily modularized and spread out across many repositories and API docs).
-
I will definitely try out the second option, thank you. Commented Mar 2, 2020 at 8:24
I've not used these plugins but I am using pipelines and pipeline libraries (https://jenkins.io/doc/book/pipeline/shared-libraries/).
My Jenkinsfile is now dead simple basically made of an import, I define a map for project specific parameters and call the function from the import with the map :
@Library('lib-pipeline')
def config = ["project_code":"ProjA",
"phase_code":"prod",
"build_NET":"YES",
"build_mono":"NO",
"run_tests":"YES",
"run_tests_coverage":"YES",
"p4_credential":"MY_CREDENTIAL"
]
BuildWithMapConfig(config)
All the actual code is in a git repo where we can track changes properly. you can set a branch in your import
@Library('lib-pipeline@develop')
This coupled with the retry option in Jenkins where you can modify the Jenkinsfile just for that run makes it super easy to test variants in this pipeline.
Having it all in a separate library I imagine you could de-couple the groovy script in a way that makes them unit testable on their own. You could add a pipeline to that project to run these tests and other validations too.
Since I've never used these plugins I'm not exactly sure this is what you are looking for, but if I had to add these functionalities in my pipeline that would be how I would do it.
-
1I'm not sure this answers the question. I think the question is asking about Active Choice Parameters specifically - these type of parameters use Groovy scripts (which are separate from Pipeline code) to generate parameter configuration on-the-fly in the "Build With Parameters" web UI page. (Pipeline code, by contrast, can only generate parameter configuration when executing the pipeline.) Commented Feb 29, 2020 at 6:52