There is declarative pipeline. In the beginning of pipeline block the agent selection is made using agent directive. Label-based selection is being conducted. Agent selected this way is the standard/default agent.
How to set for whole pipeline a special agent when certain condition is met?
The plan is to do condition check based on pipeline's one parameter >> can that work?
What are the points the chosen approach needs to address?
Current solution blueprint:
Groovy code prior to pipeline block
Mentioned groovy code sets a variable based on value of pipeline's parameter how to access pipeline's parameter from within Groovy code located out of pipeline?
agent section uses variable set in Groovy code matching label special agent got attached to
Both Jenkins.io and Cloudbees do not support dynamic agent selection with Declarative Pipeline syntax. Hence adding "when" expression within agent block will not work. However, the below approach can be tried
1. Create pipeline library - with a groovy file in vars folder. Keep all the stages inside this file and parameterize the "Agent" block
2. Jenkinsfile - embed the library inside Jenkinsfile and invoke the above groovy file using call(body) syntax. Pass agent deciding parameter from this Jenkinsfile.
For library syntax, please refer this url
Shared Library syntax
Related
I need to pass a list of parameters to Jenkins from a file written in this way
param1=test1
param2=test2
paramBool=true
....
How can I pass these parameters?
I have to use the parameters in a Jenkins pipeline
I mentioned before a dynamic declarative pipeline parameters.
You might combine it with:
either readFile
or load, which can evaluate a Groovy source file into the Pipeline script, and modify params.
In my Jenkins system configuration page, I have 3 variables defined, namely, sandbox_deployed, staging_deployed, and production_deployed. In my pipeline, I want to access one of these variables, based on a pipeline property, BUILD_ENV, defined in the job's configuration page. In other words, in my job's configuration page I have
BUILD_ENV=sandbox
How can I write pipeline code that does
println "$env.${env.BUILD_ENV}_deployed"
If I write it like in the above println, I get
org.jenkinsci.plugins.workflow.cps.EnvActionImpl#336841dd.sandbox_deployed
But I really want this
println "env.sandbox_deployed"
which prints out the correct value of the sandbox_deployed variable.
Try this code, at least it worked for me
println "${env."${env.BUILD_ENV}_deployed"}"
I am trying to implement a Jenkins pipeline whereby I want to control the source code for the pipeline code in git.
To declare my parameters in a Declarative pipeline, I'll have to adhere to the following syntax:-
...
pipeline {
parameters {
...
}
...
}
For the parameters section, how can I declare an Active Choice Reactive parameter, so that I can programatically populate the choices using a groovy script?
I know this is possible using the Jenkins UI using the Configure pipeline option, however I am trying to understand how I can implement this behavior in Groovy code.
Thank you
Jenkins dynamic declarative pipeline parameters
Look at solution in post #5, not the accepted. It works well always.
This is the only way for now cause Active Choices (AC) built for scripted pipelines and not straightforward support declarative pipelines.
I work a lot with AC in declarative pipelines, so my own decision is always move all the properties (parameters) wrote in scripted way before "pipeline" and even use it in Shared Libraries (as init function) or load from disc if needed and all other pipeline writing in declarative way to get all the advantages of both.
Additional benefit of that trick that I can reuse pipeline with different parameters cause loading them on the fly from Git or Shared Libraries.
Found lifehack:
To built Groovy script of different codes and AC types go to pipeline syntax constructor, select "input" > "This build is parametrized" > add there needed AC > fill all the fields and choose options as needed (same as in Job UI) > Generate code. After just copy "properties block" or part of AC code and put it in your Jenkinsfile before "pipeline".
I have a parameterized project. With the variable VAR1.
I'm using the the Xray for JIRA Jenkins Plugin for Jenkins. There you can fill four parameters:
JIRA Instance
Issues
Filter
File Path
I'm new to Jenkins but what I have learned so far, that you can't fill this fields with environment variables. Something like
Issues: ${VAR1} - doesn't work.
So I thought I can do this with a pipeline. When I click on Pipeline Syntax and chose step: General Build Step I can choose Xray: Cucumber Features Export Task. Then I fill the fields with my environment variable and click Generate Pipeline Script The output is as follows:
step <object of type com.xpandit.plugins.xrayjenkins.task.XrayExportBuilder>
That doesn't work. What I'm doing wrong?
All you're doing is OK, but what you want is not supported by Jenkins whether it is pipeline or not, since the parameters' load is happening prior to the pipeline-flow or the definition of the ${VAR1}.
You can try to overcome this by defining the 'Issues' value as a pipeline internal value instead of a parameter and base it on the ${VAR1} value.
If it must be a parameter, use 2 jobs where one defines the value of 'Issues' based on a the ${VAR1} and pass it to the other job that gets the 'Issues' as a fixed value.
There is a job parametrized with Active Choices Parameters using Active Choices Plugin
I want to trigger this job from the upstream job.
The upstream job should use the default parameters of the downstream job.
The parameter UtilityPath depends on UtilityVersion to evaluate itself and to form the list of choices.
How can I
Get the list of choices returned by the groovy script of UtilityVersion from the upstream job?
Supply my choice for UtilityVersion to the parameter UtilityPath, so it could generate it's own list of choices for me (again, on the upstream job).
Trigger the job with my choices for parameters UtilityVersion and UtilityPath?
Whatever your downstream job's parameter has (in the groovy script/ code section), if you can put that in a SCRIPTLER script (see Jenkins Scriptler plugin) then you can call that scriptler script and pass the same parameters (that you were passing in the downstream job) in your upstream job's BUILD section (either execute shell or Run Groovy script) as you mentioned, you don't want to add the same downstream parameters in your upstream job due to complexities). NOTE: See conditional run plugin on how to call Scriptler script (in Build section) if you don't want to call the Scriptler script if you are dealing with TFS vs ProjectC vs someAutomationD or when parameterX is set to true (your call there).
It's pretty much same what CSchulz mentioned but Scriptler script is better as you change the code/script in one place (Scriptler Script section - left hand side section on Jenkins home page) and then use/reuse that script anywhere (i.e. either in parameters which support Groovy Scriptler script --or-- in the build section) without requiring to read a downstream job's parameter values (some hacky way before even the downstream is called, time changes everything sometimes) --OR doing something crazy with Jenkins API to make it more complex.
As I have tried, you cannot trigger upstream/downstream jobs with "Active Choice Plugin". Active choice and Reactive parameters get fired only if you trigger the job manually. For instance, if you tried to trigger the build from a bitbucket, active choice parameter get the value but reactive value will be shown as empty.
But you can achieve this in different ways.
If you are triggering the first job manually (by yourself), set the downstram job parameters as string so you can read those values directly.
Second option is to use environmental variable. Active choice is more over a conditional choice parameter. you can write groovy script to set parameters as environmental variable.This can be achieved with EnvInject Plugin. Write your conditional script in groovy and parameters are available in each and every build steps.
use environment variables to pass parameters to downstream job