I have two Jenkins nodes, but only one node can be ran on special parameter, how do I add restriction to the master that if the parameter was set to true the job will run on target node?
You can configure to accept a parameter that indicate if its special or not.
In jenkins groovy job just use a conditional if to check if parameter is send as special one or its normal accordingly you can create a new variable like
def Agent_Var = Special_Agent (The label of special agent)
Note - please configure label for the agents to determine which agent to use.
after setting up Agent_Var variable you can define Agent_Var label in pipeline as below -
pipeline {
agent { label "$Agent_Var " }
Related
I would like to execute my job in a remote node passing the domain name as node arg.
Someone knows how to build this jenkinsfile?
I can't execute on the below way
node('jenkins.mydomain.com') {
build 'remote_exec'
}
There are actually two major issues within your two lines of code :-)
node('jenkins.mydomain.com') {
This will build on a build agent with the label jenkins.mydomain.com. If you have only one build agent with this label given, this should work. But it's not the hostname! (Note: I'm not entirely sure if dots are allowed, but you could call it also whateverserver).
So this would allocate an executor slot (to run the code within the closure) on a build agent matching the given label...
build 'remote_exec'
and then trigger yet another build for the job called remote_exec. This job (assuming it exists and you don't have this as a third issue^^) will then be built on an agent matching its own labels, ignoring the one given in the node(label) step.
If you want that the remote_exec job runs on a specific build agent only, then add the node step there!
I have created a Global choice Parameter using Extensible Choice Parameter plugin.
I am using this parameter list in one of my parametrized jenkins job.
Is there a way in jenkins, where I can execute the job with each of the parameters in the Global choice Parameter list?
I have had a look on Build Flow job in jenkins, as suggested in this answer, but it seems it accepts hardcoded parameters only, and not dynamic.
I finally managed to resolve this using the following steps (with great help from this post) -
As my parameters list is dynamic in nature, it could be added or modified according to other jobs, we have managed it in a text file.
Next, We have used Extensible Choice Parameter plugin to display the parameters, using the groovy script -
def list = [];
File file = new File("D:/JenkinJob/parameterList.txt")
file.eachLine { line ->
list.add("$line")
}
return list
Now I want to call this jenkins job for each of the parameter.
For this, I have installed, BuildFlow plugin, and crated a new jenkins job of BuildFlow type -
Next, get the Extended Choice Parameter plugin, and configure it as follows -
Now in the flow step of this job, write this script, where "Feature" is the parameter, that is just created above, and within call to "build" parameter, pass in the name of job which we want to call for each parameter -
def features = params['Features'].split(',')
for (feature in features ) {
build("JobYouWantToCall", JobParameter: feature,)
}
I wish to set the build name based on some condition.
Eg:
if the branch name( input parameter)= development
then build name= development
if the branch name = master then build name= master.
I can able to set the build name by using build name setter plugin but i need this based on condition.
Assuming that you use Free Style jobs, then you can use the Groovy plugin to execute arbitrary groovy code which has access to the Java structures for the build and Jenkins.
Simply add an Execute system Groovy scriptstep and enter your code which determines the name, then use build.setDisplayName() to set the name.
So similar to your example, here is a name setter which sets the name depending on the value of build parameter branch_name:
if (build.buildVariableResolver.resolve("branch_name").equals('master')) {
build.setDisplayName("Master build #${build.getNumber()}")
} else if (build.buildVariableResolver.resolve("branch_name").equals('development')) {
build.setDisplayName("Development build #${build.getNumber()}")
} else {
build.setDisplayName("Other build #${build.getNumber()}")
}
if the branch name( input parameter) = development then build name=
development
Assuming you are providing the branch name as a parameter and want to set the build name as the same using the name setter plugin, you should be able to configure it.
You can use the same parameter name as environment variable in the setter plugin as ${ENV,var="my-special-branch"}
If you want to set build name to a job from a parameter, you can use
currentBuild.displayName = "${nameOfYourParameter}"
Job Configuration
Buil job with parameters
Build History
Ref: How to set build name in Pipeline job?
I am triggering a job (child job) in 'Server B' from a job (parent job) in 'Server A' through a python script. I have 2-3 parent jobs. So I want to know which parent job is triggered the child job. How can I know which parent job triggered child job?
Can I pass the parent job name to child job name ?
Or
Can I get the parent name directly from child job ? (Environment variable / using python scripts)
Every build has an environment variable JOB_NAME. You can pass this as a string parameter to your child job.
Following description is provided in the /env-vars.html:
JOB_NAME
Name of the project of this build, such as "foo" or "foo/bar". (To strip off folder paths from a Bourne shell script, try: ${JOB_NAME##*/})
Passing the job name as an environment variable as mentioned by OltzU, may be the way to go, but that depends on how you are triggering the child job. If you are directly triggering the child job from the parent job using a post-build step, you can use something like the Parameterized Remote Build plugin to pass the Job name along. If you are using a script in the parent job to fire off the child job, you can string the Job name on as a parameter.
If you can't pass the triggering job as a parameter, you can programmatically get the build trigger(s) using Groovy. Groovy is really the only language that fully integrates with the Jenkins api, so if you want to use another language (python), you are stuck with using the rest api or jenkins cli, which are both limited in what they can give you (e.g. neither can give you the triggering job to my knowledge).
If you want to use groovy to get the trigger job, you will need the Groovy Plugin, which you will run as build step in your child job. Here's a snippet of code to get the chain of upstream jobs that triggered your build. You may need to modify the code depending on the type of trigger that is used.
def getUpstreamProjectTriggers(causes) {
def upstreamCauses = []
for (cause in causes) {
if (cause.class.toString().contains("UpstreamCause")) {
upstreamCauses.add(cause.getUpstreamProject())
}
}
return upstreamCauses
}
getUpstreamProjectTriggers(build.getCauses())
From here, if you want to use the triggering job in, say, a python script, you would need to use groovy to set the triggering job in an environment variable. This SO thread gives more info on that, or you can skip to my answer in that thread to see how I do it.
In the child Jenkinsfile this Groovy code will get the name of the triggering job:
String getTriggeringProjectName() {
if (currentBuild.upstreamBuilds) {
return currentBuild.upstreamBuilds[0].projectName
} else {
return ""
}
}
currentBuild.upstreamBuilds is a list of RunWrapper objects
You could use an additional parameter for your child job.
I wan't to be able to temporary exclude a specific job from running on a node in a label group.
jobA, jobB, jobC are tied to run on label general
nodeA,nodeB,nodeC have the label general on them.
Let's say that jobA starts to fail consistently on nodeA.
The only solutions that I see today are taking nodeA offline for all jobs or reconfigure many jobs or nodes which is pretty time consuming. We are using JOB-DSL to configure the jobs so changing in the job configuration requires a checkin.
An ideal situation for us would be to have a configuration on the node:
Exclude job with name: jobA
Is there some easy way to configure that jobA should temporarily only run on nodeB and node C and that jobB/C should still run on all nodes in label general?
Create a parameterized job to run some job-dsl configuration. Make one of the parameters a "Choice" listing the job names that you might want to change.
Another parameter would select a label defining the node(s) you want to run the job on. (You can have more than one label on a node).
The job-dsl script then updates the job label.
This groovy script will enable/disable all jobs in a folder:
// "State" job parameter (choice, DISABLED|ENABLED)
def targetState = ('DISABLED'.equalsIgnoreCase(State))
// "Folder" job parameter (choice or free-text)
def targetFolderPath = Folder.trim()
def folder = findFolder(jenkins, targetFolderPath)
println "Setting all jobs in '${folder.name}' to '${targetState}'"
for (job in folder.getAllJobs()) {
job.disabled = targetState
println "updated job: ${job.name}"
}
I just came across the same issue, I want the job to run on the device with lable, say "lableA", but do not want it to run on device with lable "lableB".
We may try this:
node(nodeA && !nodeB) {
}
Refer to: https://www.jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#node-allocate-node
you can also use NodeLabel Parameter Plugin in jobA. Using this plugin you can define nodes on which the job should be allowed to be executed on. Just add parameter node and select all nodes but nodeA.
https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin
For a simple quick exclude, what I think the original question refers to as "The only solutions that I see today are ... reconfigure ... jobs or nodes" see this other answer: https://stackoverflow.com/a/29611255/598656
To stop using a node with a given label, one strategy is to simply change the label. E.g. suppose the label is
BUILDER
changing the label to
-BUILDER
will preserve information for the administrator but any job using BUILDER as the label will not select that node.
To allow a job to run on the node, you can change the node selection to
BUILDER||-BUILDER
A useful paradigm when shuffling labels around.
NOTE that jobs may still select using the prior label for a period of time.