patternMinor
Jenkins: Access job/plugin configuration values inside pipeline
Viewed 0 times
pipelinejenkinspluginvaluesconfigurationjobaccessinside
Problem
I am trying the access the values set on a job's configuration page from within my pipeline. These values are not made available as params, nor are they injected as envvars.
Setup
Problem
Ordinarily, one would have a Jenkinsfile in the root of the repo and therefore the scm would be associated with the repo we want to checkout and build. However, in my case the code I want to build is in a different repo to the Jenkinsfile (hence the Remote Jenkinsfile Provider plugin).
This means that I need to checkout the code I wish to build as an explicit step in the pipeline, and to do that I need to know the repo. This repo is, however, already defined in the job config.
The Branch Source plugin does export things like the branch name or merge request number/branch/target into appropriate envvars, but NOT the actual repo.
As this is a multibranch pipeline, I cannot use something like envInject either (multibranch jobs do not provide the option to 'Prepare an environment for the run' as with other jobs)
Goal
I would like to be able to access the
Is there some clever way of accessing a job's config from within the pipeline?
Thanks for any suggestions!
Reference images
Setup
- Jenkins, v2.263.1
- GitLab Branch Source plugin, v1.5.3 (link)
- Multibranch pipeline job which is pointed to a Gitlab repo
- Remote Jenkinsfile Provider, v1.13 (link)
Problem
Ordinarily, one would have a Jenkinsfile in the root of the repo and therefore the scm would be associated with the repo we want to checkout and build. However, in my case the code I want to build is in a different repo to the Jenkinsfile (hence the Remote Jenkinsfile Provider plugin).
This means that I need to checkout the code I wish to build as an explicit step in the pipeline, and to do that I need to know the repo. This repo is, however, already defined in the job config.
The Branch Source plugin does export things like the branch name or merge request number/branch/target into appropriate envvars, but NOT the actual repo.
As this is a multibranch pipeline, I cannot use something like envInject either (multibranch jobs do not provide the option to 'Prepare an environment for the run' as with other jobs)
Goal
I would like to be able to access the
server, owner and project fields set in the job config page. Ultimately I could manage with just the project's ssh/http address even.Is there some clever way of accessing a job's config from within the pipeline?
Thanks for any suggestions!
Reference images
Solution
This is possible, but you'll have to use scripted Pipelines, not declarative, disable the Groovy sandbox for pipelines, and dig deep into the Jenkins API.
For instance, I wrote a Pipeline job that edits the parameters of a second job which has a full name of "SCA/deploy_to_environment/master". Here's a snippet of that code - I'm eliding how to create the "Param" objects in the first line for brevity, this snippet is just to give you an idea of what a similar use case looks like:
So to fetch the values instead of simply editing them, you would need to instead call
However, I have to ask, why do you want to do this? What's the big picture here?
It sounds kind of like you want to share a single Jenkinsfile or build pipeline among multiple repositories. I also have this use case at my job - we need to have one Jenkinsfile shared across nearly 200 repositories. If this is similar to your need, then consider using Jenkins Shared Libraries. You can put all of your build pipeline code into a single shared library, then call the shared library in a single line from the Jenkinsfile in your individual repositories.
For instance, I wrote a Pipeline job that edits the parameters of a second job which has a full name of "SCA/deploy_to_environment/master". Here's a snippet of that code - I'm eliding how to create the "Param" objects in the first line for brevity, this snippet is just to give you an idea of what a similar use case looks like:
def paramProp = new ParametersDefinitionProperty(envParam, pgParam, infoParam)
def job = Jenkins.instance.getItemByFullName('SCA/deploy_to_environment/master')
// There is no "setProperty" - we need to remove and replace.
// removeProperty is safe to run even if no matching properties are set on the job.
// However, this method only removes one property per method call.
// Theoretically, this means the job could accumulate multiple conflicting
// ParametersDefinitionProperty properties.
// TODO: run removeProperty in a while loop to eliminate all matching properties for extra safety.
job.removeProperty(ParametersDefinitionProperty)
job.addProperty(paramProp)So to fetch the values instead of simply editing them, you would need to instead call
getProperty (API doc here), passing the class name of the GitLab Project parameter classes. I suspect the class name you'll need is available somewhere in the source code or the API docs for that plugin, but I'm not sure.However, I have to ask, why do you want to do this? What's the big picture here?
It sounds kind of like you want to share a single Jenkinsfile or build pipeline among multiple repositories. I also have this use case at my job - we need to have one Jenkinsfile shared across nearly 200 repositories. If this is similar to your need, then consider using Jenkins Shared Libraries. You can put all of your build pipeline code into a single shared library, then call the shared library in a single line from the Jenkinsfile in your individual repositories.
Code Snippets
def paramProp = new ParametersDefinitionProperty(envParam, pgParam, infoParam)
def job = Jenkins.instance.getItemByFullName('SCA/deploy_to_environment/master')
// There is no "setProperty" - we need to remove and replace.
// removeProperty is safe to run even if no matching properties are set on the job.
// However, this method only removes one property per method call.
// Theoretically, this means the job could accumulate multiple conflicting
// ParametersDefinitionProperty properties.
// TODO: run removeProperty in a while loop to eliminate all matching properties for extra safety.
job.removeProperty(ParametersDefinitionProperty)
job.addProperty(paramProp)Context
StackExchange DevOps Q#13203, answer score: 2
Revisions (0)
No revisions yet.