Answers: <p>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.</p>
  <p>For instance, I wrote a Pipeline job that edits the parameters of a second job which has a full name of &quot;SCA/deploy_to_environment/master&quot;.  Here's a snippet of that code - I'm eliding how to create the &quot;Param&quot; objects in the first line for brevity, this snippet is just to give you an idea of what a similar use case looks like:</p>
  <pre><code>def paramProp = new ParametersDefinitionProperty(envParam, pgParam, infoParam)
  
  def job = Jenkins.instance.getItemByFullName('SCA/deploy_to_environment/master')
  
  // There is no &quot;setProperty&quot; - 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)
  </code></pre>
  <p>So to fetch the values instead of simply editing them, you would need to instead call <code>getProperty</code> (<a href="https://javadoc.jenkins.io/hudson/model/Job.html#getProperty-java.lang.Class-" rel="nofollow noreferrer">API doc here</a>), 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 <a href="https://javadoc.jenkins.io/plugin/gitlab-branch-source/io/jenkins/plugins/gitlabbranchsource/package-summary.html" rel="nofollow noreferrer">API docs for that plugin</a>, but I'm not sure.</p>
  <hr />
  <p>However, I have to ask, why do you want to do this?  What's the big picture here?</p>
  <p>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 <a href="https://www.jenkins.io/doc/book/pipeline/shared-libraries/" rel="nofollow noreferrer">Jenkins Shared Libraries</a>.  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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-27T23:58:23.393Z
Answers: Thank you for this - I will give it a try.  Yes, you're correct, I could (and do) use shared libraries.  I ask, in part, because I guess the bad actor in me knows how I could abuse a Jenkinsfile in a source repo so try to avoid them, and in part simply because I'm curious. I've got a workaround which is to construct a config file for the job which contains the same repo urls as in the job's config. This can then be read by the pipeline using configFileProvider().  It works, and at least I can use JobDSL to do this for me.
Answers: Denham Coote
Answers: CC BY-SA 4.0
Answers: 2021-01-27T01:47:44.453Z
Answers: 2021-01-27T01:47:44.453Z
Answers: jayhendren
Body: <p>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.</p>
  <p><strong>Setup</strong></p>
  <ul>
  <li>Jenkins, v2.263.1</li>
  <li>GitLab Branch Source plugin, v1.5.3 (<a href="https://github.com/jenkinsci/gitlab-branch-source-plugin" rel="nofollow noreferrer">link</a>)</li>
  <li>Multibranch pipeline job which is pointed to a Gitlab repo</li>
  <li>Remote Jenkinsfile Provider, v1.13 (<a href="https://github.com/jenkinsci/remote-file-plugin" rel="nofollow noreferrer">link</a>)</li>
  </ul>
  <p><strong>Problem</strong></p>
  <p>Ordinarily, one would have a <em>Jenkinsfile</em> 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 <em>Remote Jenkinsfile Provider</em> plugin).</p>
  <p>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.</p>
  <p>The <em>Branch Source</em> plugin does export things like the branch name or merge request number/branch/target into appropriate envvars, but NOT the actual repo.</p>
  <p>As this is a multibranch pipeline, I cannot use something like <em>envInject</em> either (multibranch jobs do not provide the option to 'Prepare an environment for the run' as with other jobs)</p>
  <p><strong>Goal</strong></p>
  <p>I would like to be able to access the <code>server</code>, <code>owner</code> and <code>project</code> fields set in the job config page. Ultimately I could manage with just the project's ssh/http address even.</p>
  <p><strong>Is there some clever way of accessing a job's config from within the pipeline?</strong></p>
  <p>Thanks for any suggestions!</p>
  <p><strong>Reference images</strong></p>
  <p><a href="https://i.sstatic.net/W6GtY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/W6GtY.png" alt="GitLab Branch Source settings in job config" /></a>
  <a href="https://i.sstatic.net/0CGNu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/0CGNu.png" alt="Remote Jenkinsfile Provider settings in job config" /></a></p>
  
Tags: <jenkins><jenkins-pipeline><gitlab><jenkins-plugins><jenkinsfile>
Title: Jenkins: Access job/plugin configuration values inside pipeline
UserDisplayName: Denham Coote
ThreadText: # Jenkins: Access job/plugin configuration values inside pipeline
  
  (Asked by: username_0 on 2021-01-22)
  
  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**
  
  * Jenkins, v2.263.1
  * GitLab Branch Source plugin, v1.5.3 ([link](https://github.com/jenkinsci/gitlab-branch-source-plugin))
  * Multibranch pipeline job which is pointed to a Gitlab repo
  * Remote Jenkinsfile Provider, v1.13 ([link](https://github.com/jenkinsci/remote-file-plugin))
  
  **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**
  
  [![GitLab Branch Source settings in job config](https://i.sstatic.net/W6GtY.png)](https://i.sstatic.net/W6GtY.png)
  [![Remote Jenkinsfile Provider settings in job config](https://i.sstatic.net/0CGNu.png)](https://i.sstatic.net/0CGNu.png)
  
  **Tags:** jenkins, jenkins-pipeline, gitlab, jenkins-plugins, jenkinsfile
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-01-27. Score: 2 | Accepted answer
  
  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:
  
  ```
  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](https://javadoc.jenkins.io/hudson/model/Job.html#getProperty-java.lang.Class-)), 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](https://javadoc.jenkins.io/plugin/gitlab-branch-source/io/jenkins/plugins/gitlabbranchsource/package-summary.html), 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](https://www.jenkins.io/doc/book/pipeline/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.
  
  > **Comments:**
  > **username_0**: Thank you for this - I will give it a try.  Yes, you're correct, I could (and do) use shared libraries.  I ask, in part, because I guess the bad actor in me knows how I could abuse a Jenkinsfile in a source repo so try to avoid them, and in part simply because I'm curious. I've got a workaround which is to construct a config file for the job which contains the same repo urls as in the job's config. This can then be read by the pipeline using configFileProvider().  It works, and at least I can use JobDSL to do this for me.  
  
  ---
  
  