Can I change the way Jankins names the workspace for concurrent jobs? Currently it uses the #2, #3 when running concurrent builds. I would like to change the "#" to another character. Is this possible. It is causing problems further down in my jobs.
Workspace created for concurrent job #2:
in workspace /devsrc/jenkins/workspace/CKPT_vw5.2_ubuntu#2
Further down in build script:
The environment variable II_SYSTEM contains characters that are not
allowed. The path should only contain alphabetic, digit, period,
underscore and hyphen characters.
+ [ ! -f /devsrc/jenkins/workspace/CKPT_vw5.2_ubuntu#2/ingres/files/config.dat ]
+ exit 1
I didn't test this before posting, but I've used these types of parameters in the past with no problems. See features controlled by system properties. In there, there's one to change the # to something else:
"hudson.slaves.WorkspaceList" (default value: #)
When concurrent builds is enabled, a unique workspace directory name is required for each concurrent build. To create this name, this token is placed between project name and a unique ID, e.g. "my-project#123".
In Ubuntu, I would edit /etc/default/jenkins and add this to the "JAVA_ARGS" property and say use "A" instead of "#". And of course you'll need to restart Jenkins.
-Dhudson.slaves.WorkspaceList=A
Related
I have a Jenkins server built on a Windows PC, when it builds my project it adds the word Pipeline with a space character separator to the project in the workspace. The value ${ITEM_FULL_NAME} is safe from an OS point of view but I have a problem with a process (Xilinx Memory Interface Generator) that runs in the pipeline that cannot cope with spaces in the path (it is bad that that process cannot cope with space characters in directories but I am stuck with it). Is there a way to ensure the generated ${ITEM_FULL_NAME} variable does not contain space characters?
I have tried to work around the issue by creating a Power Shell script to rename the directory using the underscore character but as feared I cannot do this as a process is running on the folder.
I have looked at the Whitespace plugin but I think this is for inputs into the pipeline not for what Jenkins generates.
I also looked at Restrict Project Naming but again think this is for project input and not what is generated by Jenkins.
Any suggests gratefully received; I am new to Jenkins so if you have a solution it might need spelling out, thank you.
You can use trim to remove the white spaces:
ITEM_FULL_NAME= ITEM_FULL_NAME.trim()
Another way :
If the variable is a parameter variable then you can use below:
parameters { string(defaultValue: "", description: '', name: 'ITEM_FULL_NAME', trim: true) }
I want to get the number inside the _work folder of an on-premise TFS agent.
For example:
From C:/agent/_work/1 get the 1.
Is there a variable to get the 1 part?
You can use a small PowerShell script to extract the number and set a new variable for the sequences steps:
$folderPath = "$env:Agent_BuildDirectory"
$folderNumber = $folderPath.Split('\')[$folderPath.Split('\').Count - 1]
Write-Host "##vso[task.setvariable variable=folderNumber]$folderNumber"
Now you can use the variable $(folderNumber) in the sequences tasks.
There is no reason for you to parse this information out. The current working folder for a given build or release is accessible in the variable $(Agent.BuildDirectory).
If you are trying to reference the working folder of a different build, then you are doing something wrong with your build process, and there are a number of different, valid solutions to that problem.
Check out the different variable values and ways to customize them if needed. Note the Agent.DeploymentGroupId is is not something you would change.
Release variables and debugging
Agent.DeploymentGroupId
The ID of the deployment group the agent is registered with. This is available only in deployment group jobs.
Example: 1
Agent.WorkFolder
The working directory for this agent, where subfolders are created for every build or release. Same as Agent.RootDirectory and System.WorkFolder.
Example: C:\agent_work
I would not have believed this if I had not seen it with my own eyes. In any sort of build step (we have tried multiple types) the term http(s)://api.DOMAIN.com is replaced with https://licensing.domain.com.
We have verified the behavior on two different computers (one Mac, one Windows 10).
Both licensing.domain.com and api.domain.com are valid domain names. licensing.domain.com is used in other jobs.
It occurs at the time of saving with any job that we create or edit. If we create a job and add a build step that should print https://api.domain.com it prints https://licensing.domain.com.
It occurs with any type of build step.
The text is modified in the configuration of the job build step.
The job does not have to be executed. It occurs when it is saved at the time of creation or when it is edited.
https://api.domain.com => https://licensing.domain.com
But when we join the protocol (HTTP or HTTPS) to the domain name, we do not experience the issue.
'https://' + 'api.domain.com' => https://api.domain.com
Changing the domain extension does not change the string.
http://api.domain.net => https://api.domain.net
I was intimately involved in setting up the system and I have not created anything that to my knowledge would cause this to occur.
We are using Jenkins Pipeline Multibranch Plugin with Blue Ocean.
Through my reading, I believe it is quite common to tie your project's build number to the Jenkins run, as this allows traceability from an installed application through to the CI system, then to the change in source control, and then onto the issue that prompted the change.
The problem is that for each branch, the run number begins at 0. For a project with multiple branches, it seems impossible to guarantee a unique build number.
You can get the Git branch name from $GIT_BRANCH and add this to $BUILD_NUMBER to make an ID that's unique across branches (as long as your company doesn't do something like get themselves taken over by a large corporation that migrates you to another Jenkins server and resets all the build numbers: to protect against that, you might want to use $BUILD_URL).
Only snag is $GIT_BRANCH contains the / character, plus any characters you used when naming the branch, and these may or may not be permitted in all the places where you want an ID. ($BUILD_URL is also going to contain characters like : and /) If this is an issue, one workaround would be to delete unwanted characters with tr:
export MY_ID=$(echo $GIT_BRANCH-$BUILD_NUMBER | tr -dc [A-Za-z0-9-])
(-dc means delete the complement of these characters, so A-Z, a-z, 0-9 and - are the characters you want to keep.)
Maybe instead of a unique (global numeric) build number you might want to try a unique (global) build display name?
According to "pipeline syntax: global variables reference" currentBuild.displayName is a writable property. So you could e.g. add additional information to the build number (in order to make it globally unique) and use that string in subsequent artifact/application build steps (to incorporate that in the application's version output for your desired traceability), e.g. something like:
currentBuild.displayName = "${env.BRANCH_NAME}-${currentBuild.id}"
Using the build's schedule or start time formatted (currentBuild.timeInMillis) as a readable date, or using the SCM revision might be also useful, e.g. resulting in "20180119-091439-rev149923".
See also:
https://groups.google.com/forum/#!msg/jenkinsci-users/CDuWAYLz2zI/NLxwOku4AwAJ
https://support.cloudbees.com/hc/en-us/articles/220860347-How-to-set-build-name-in-Pipeline-job
One way is to have a Job that is being called from all branches and using it's build number. That job can be just a normal pipeline job with a dummy Jenkinsfile like echo "hello". Then just call it like this
def job = build job: 'build number generator', quietPeriod: 0, parameters: [
string(value: "${BRANCH_NAME}-${BUILD_NUMBER}", name: 'UID')
]
def BNUMBER = job.getNumber().toString()
currentBuild.displayName = "build #"+BNUMBER
echo BNUMBER
Not sure if that UID parameter is needed but it forces all calls into "build number generator" job to be unique so Jenkins wouldn't optimize builds that happen at same time to use same "build number generator" job.
You can use an external service to manage a unique build number for your project. It helps to get unique build numbers across branches and across CI servers too.
https://www.nextbuildnumber.net/
I need to know if there is a plugin of some sort that you can select a node from a jenkins job and use that node name as a parameter to be passed to a Windows batch command
I have played with the Configuration Matrix using an Elastic-Axis or Slaves (Screenshot below where you can tick the names) plugins
But these all go and execute the Windows batch command on that selected node.
I don't want to execute it on that server but rather on the main node and only pass the value of the slave/label to the windows batch command.
I were able to do it as described here but that involves 2 jobs and a groovy scripts to interrogate the slaves/nodes config. Write it to a properties file and pass the properties file to the next job.
Jenkins: How to get node name from label to use as a parameter
I need to do about 30 jobs of these and hence would like to try to do all in one job - if I used my solution in the link above, 30 jobs would double in 60 jobs and maintenance would be kind of a nightmare.
I also would not like to have a string parameter and hard code the name of the slave/node as that will not ensure the use of only the available slaves/nodes but any server name can be entered and that would can be a problem where someone can mistype a server name for example pointing to a Production server instead of a test server.
https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin
After installing this plugin you will have an option to add a Node parameter to Jenkins job. It will have a list of all slaves available on current master.
You can use the active choice parameter plugin
https://plugins.jenkins.io/uno-choice/
with a little groovy script to list node names in a parameter selection box.