I have a freestyle job and a parameterized build.
I want to populate an Extensible Choice with all xml file names inside my workspace.
Both the job and the workspace are running on the slave.
The textbox Base Directory says that every relative path has JENKINS_HOME as root, and that is the Jenkins location on the master. Something like C:/ has the same outcome.
I have the same problem with the Active Choice Parameter.
I don't know how to get access to my workspace, with the groovy script for my parameter.
I've tried the following:
def list = []
def dir = new File("C:/<path>")
dir.eachFileRecurse (FileType.FILES) { file ->
list << file
}
It results in a FileNotFoundException. When I try to input a path to the master, it works fine.
I labeled the slave and the job correctly (The job will only be executed on the slave).
Does anyone has a solution?
Related
I try to configure Jenkins' seed job, where whole business is in provided DSL script. I want to seperate that script from its configuration, which I want to locate in additional yml file. When I try to read that file:
#Grab('org.yaml:snakeyaml:1.17')
import org.yaml.snakeyaml.Yaml
def workDir = SEED_JOB.getWorkspace()
def config = new Yaml().load(("${workDir}/config.yml" as File).text)
I receive error
java.io.FileNotFoundException: /var/lib/jenkins/workspace/test.dsl/config.yml (No such file or directory)
I suppose that Jenkins is looking for the file on a master host, not an agent node where workspace is located.
Is it possible to read yml file in DSL build step on the agent node? Or maybe I have to execute that seed job always on my master host?
This seems not possible as the jobDsl script is executed on master. You can try force to run the job on master with label master.
From the documentation in section Script location:
Job DSL scripts are executed on the Jenkins master node, but the seed job's workspace which contains the script files may reside on a build node. This mean that direct access to the file specified by FILE may not be possible from a DSL script. See Distributed builds for details.
I have some groovy code which I am planning to re-use in Jenkins Groovy Post Build plugin of multiple jobs. How can I achieve this? Is there a place I can store the script in a global variable and call that in the jobs where ever I need?
You can load any groovy file living on the Jenkins master within the groovy postbuild and execute it. For example, you could have a special directory on the c drive where all the common scripts live. I'll update my answer later with some code that shows you how to load the script in.
Update
Assuming you have a test.groovy file on your C: drive, it should be as simple as the following in Groovy Postbuild:
evaluate(new File("C:\\test.groovy"))
Please view the comment section of the Groovy Postbuild for more examples and possibly other ways.
Here is the solution that worked for me:
Installed Scriptler plugin for Jenkins and saved the Groovy script in that. Now the script is available in JENKINS_HOME/scriptler/scripts directory. This way we can avoid manual step of copying files to Jenkins master.
Used the groovy file in Post build:
def env = manager.build.getEnvironment(manager.listener) evaluate(new File(env['JENKINS_HOME'] + "\\scriptler\\scripts\\GroovyForPostBuild.groovy"))
This is a copy of my answer to this similar question on StackOverflow:
If you wish to have the Groovy script in your Code Repository, and loaded onto the Build / Test Slave in the workspace, then you need to be aware that Groovy Postbuild runs on the Master.
For us, the master is a Unix Server, while the Build/Test Slaves are Windows PCs on the local network. As a result, prior to using the script, we must open a channel from the master to the Slave, and use a FilePath to the file.
The following worked for us:
// Get an Instance of the Build object, and from there
// the channel from the Master to the Workspace
build = Thread.currentThread().executable
channel = build.workspace.channel;
// Open a FilePath to the script
fp = new FilePath(channel, build.workspace.toString() + "<relative path to the script in Unix notation>")
// Some have suggested that the "Not NULL" check is redundant
// I've kept it for completeness
if(fp != null)
{
// 'Evaluate' requires a string, so read the file contents to a String
script = fp.readToString();
// Execute the script
evaluate(script);
}
I'm currently doing some evaluation on the Jenkins Pipeline plugin (formerly know as Workflow plugin).
Reading the documentation I found out that I currently cannot retriev the workspace path using
env.WORKSPACE:
The following variables are currently unavailable inside a workflow script:
NODE_LABELS
WORKSPACE
SCM-specific variables such as SVN_REVISION
Is there any other way how to get the absolute path to the current workspace? I need this running some test which in turn gets some parameter (absolute path to some executable file).
I already tried using new File("").absolutePath() inside a #NonCPS section but looks like the non-CPS stuff gets always executed on the master.
Does anybody have a clue how to get this path without running some batch script which stores the path into some file which later on can be read in again?
Since version 2.5 of the Pipeline Nodes and Processes Plugin (a component of the Pipeline plugin, installed by default), the WORKSPACE environment variable is available again. This version was released on 2016-09-23, so it should be available on all up-to-date Jenkins instances.
Example
node('label'){
// now you are on slave labeled with 'label'
def workspace = WORKSPACE
// ${workspace} will now contain an absolute path to job workspace on slave
workspace = env.WORKSPACE
// ${workspace} will still contain an absolute path to job workspace on slave
// When using a GString at least later Jenkins versions could only handle the env.WORKSPACE variant:
echo "Current workspace is ${env.WORKSPACE}"
// the current Jenkins instances will support the short syntax, too:
echo "Current workspace is $WORKSPACE"
}
Note: this solution works only if the slaves have the same directory structure as the master. pwd() will return the workspace directory on the master due to JENKINS-33511.
I used to do it using pwd() functionality of pipeline plugin. So, if you need to get a workspace on slave, you may do smth like this:
node('label'){
//now you are on slave labeled with 'label'
def workspace = pwd()
//${workspace} will now contain an absolute path to job workspace on slave
}
"WORKSPACE" environment variable works for the latest version of Jenkins Pipeline. You can use this in your Jenkins file: "${env.WORKSPACE}"
Sample use below:
def files = findFiles glob: '**/reports/*.json'
for (def i=0; i<files.length; i++) {
jsonFilePath = "${files[i].path}"
jsonPath = "${env.WORKSPACE}" + "/" + jsonFilePath
echo jsonPath
hope that helps!!
For me WORKSPACE was a valid property of the pipeline itself. So when I handed over this to a Groovy method as parameter context from the pipeline script itself, I was able to access the correct value using "... ${context.WORKSPACE} ..."
(on Jenkins 2.222.3, Build Pipeline Plugin 1.5.8, Pipeline: Nodes and Processes 2.35)
I want to run a Jenkins job on 4 different slaves (windows, linux, solaris, Mac). Instead of making 4 different jobs I want to have a single job. I can use a Node parameter to execute on different slaves. My job runs a script which uses Jenkins workspace of slave and a few other scripts. My script is in a different folder on each slave, and other required scripts are in a different folder. So now I have created 4 different jobs for each slave and hard-coded Jenkins workspace and other required scripts path.
Is there any way so that I can put all paths in some JSON-like structure and depending on slave will pick those paths? So that I will have 1 job only.
Please suggest, Thanks in advance!
my idea is to use e.g "Execute system Groovy script" to get slave value and then use if statement to assigne proper path and create parameter visible in Environment Variables:
import hudson.model.Computer
import hudson.model.StringParameterValue
import hudson.model.ParametersAction
//get slave name
def slaveName = Computer.currentComputer().getNode().name
def path
//choose path
if(slaveName.equals("slave01")){
path = "C:"
}
if(slaveName.equals("slave02")){
path = "/root"
}
if(slaveName.equals("slave03")){
path = "D:"
}
//pass path as env. variable
build.addAction(new ParametersAction(new StringParameterValue('path', path)))
then you can use variable path in command:
echo %path%
or use Conditional BuildStep Plugin to set separable steps for each operation system and control when each step should be executed
Jenkins is designed to check out files from a version control system (Subversion, Git, whatever) and run tasks. Instead of trying to manage separate files on separate slaves, you should put your scripts in some form of version control and let Jenkins check out the files in the workspace as part of its build process.
I have 2 jobs: "Helper" and "Main" and the single jenkins instance (which is the host and the executor).
The helper manages 3rd party resource and makes the preparation for the Main job (to be precise - it creates the environment for the application to be deployed for testing).
The only artifact for the helper job is a single file with IP of the environment prepared especially for the Main job.
How would I pass back the build from the Helper to the Main in this case?
You are saying that you only need to pass a file with an IP to the "Main" job. If all you need is that IP, there are easier ways of doing it (without files), I will describe both.
To pass an artifact from one job to another
In the "Helper" job, you need to archive that file from your workspace.
In post-build actions, choose Archive the artifacts
Put a path relative to the workspace. You can use wildcards, or hardcode the name of the file if it is always same.
Configure this job to automatically trigger your "Main" job using Trigger/Call builds on other projects build step. If you don't have this plugin, you can get it here
For Projects to build, enter the name of your "Main" job
Now, in the "Main" job, you need to copy this artifact from the previous ("Helper") job.
For the first build step, select Copy artifacts from another project build step. If you don't have this plugin, you can get it here
For the Project name, enter the name of your "Helper" job
For Which build, select Latest successful build
For Artifacts to copy, use **/yourartifactname*.* Your artifact name will be what you configured in "Helper" job. Using **/ in front makes sure it will ignore any directory structure before getting to the artifact
For, Target directory, specify a location in your "Main" job's workspace where this file will be copied too.
Checkmark Flatten directories, so the file goes directly to the location specified in Step 5, else it will retain the directory structure that it was archived under (in "Helper" job)
Now, your "Main" job has the file from "Helper" job in it's workspace. Use it like you would any other file in your workspace
To pass a variable from one job to another
Like I mentioned, if all you need is that one IP address, that you have as a variable at one point in time in "Helper" job, you just send it to "Main" job using the Trigger/Call builds on other projects step that you configured in steps 3 and 4 of the "Helper" job. In this case, you don't need any special configuration on "Main" job.
Configure "Helper" job to automatically trigger your "Main" job using Trigger/Call builds on other projects build step. If you don't have this plugin, you can get it here
For Projects to build, enter the name of your "Main" job
Click Add Parameters button
Select Predefined parameters
Type VarForMain=$VarFromHelper, where VarFromHelper is your environment variable from the "Helper" job that contains your IP address, and VarForMain is the environment variable that will be set in your "Main" job to this value. There is no reason why these can't have the same name.
Now, in your "Main" job, you can reference $VarForMain as you would any other environment variable
The accepted answer wasn't helpful in my case, but I've just came up with a trick:
Create a main job with a shell command of
echo "PARAMS_FILE=${WORKSPACE}/build-${BUILD_NUMBER}.params" > "${WORKSPACE}/build-${BUILD_NUMBER}.params"
Create sub-jobs by adding them to the build steps (not steps after build)
Pass the file as a parameters source to the sub-builds and have the builds updated the file with a line in their scripts like:
echo "MY_VAR=some_value" >> "$PARAMS_FILE"
That way all subsequent jobs have environment updated with the results of their predecessors.