I have a bunch of jobs triggered by commits on gitlab. The problem is, that the branch specifier in those jobs is origin/${gitlabSourceBranch}. Whenever I want to manually re-run the job I have to go inside job configuration, change it to origin/master, and than run. I want to avoid this situation and make a complete copy of all those jobs and put them into different tab, with -manual at their name's end.
My jobs look like this:
[Unit-test-tab]
ModuleName1-unit-test-python
ModuleName2-unit-test-python
ModuleName3-unit-test-java
etc...
I want to make a copy of all those jobs and put them in Jenkins under [Unit-test-tab-manual] with the same names with added -manual- at the end. So basically I want to make a tab looking like this:
[Unit-test-tab-manual]
ModuleName1-unit-test-python-manual
ModuleName2-unit-test-python-manual
ModuleName3-unit-test-java-manual
etc... (all with branch specifier changed to origin/master instead of origin/${gitlabSourceBranch)).
Is there any quick solution for this? I know I can do it manually but it is time consuming and I have a lot of those jobs. Thanks in advance! :)
You can use the Jenkins CLI to achieve what you want. It does provide a command to create jobs passing a config.xml as input.To change the branch, you can use a sed to change "origin/${gitlabSourceBranch}" to "origin/master".
You can do all this with a Jenkins Job that:
Takes the config.xml file of the job with the get-job CLI command: java -jar jenkins-cli.jar -s https://jenkins.example.com get-job JOBNAME > config.xml
Execute the sed on the config.xml of the job; the sed should be something like this: sed -i 's/origin\/${gitlabSourceBranch}/origin\/master/g' config.xml
Creates the new job with a different name using the create-job CLI command: java -jar jenkins-cli.jar -s https://jenkins.example.com create-job JOBNAME-manual < config.xml
Related
We have a Jenkins job running on a Jenkins server instance A. The current build number for this job is say 58.
We are migrating this Jenkins job to a new Jenkins server - B. However, there is a need to retain the build number - 58 from the previous server in this new Jenkins instance B.
Is this possible? If yes, how?
Thank you
If you only intend to keep the build number intact for job the in the new Jenkins Server, you could achieve it simply by writing a script that will populate the nextBuildNumber file in $JENKINS_HOME/jobs/<job_name>/ with the appropriate #buildnumber that you wish to have.
Something like this (script.sh) :-
#!bin/bash -x
JENKINS_HOME=/var/lib/jenkins
mkdir -p $JENKINS_HOME/jobs/<new_job> && cp $JENKINS_HOME/jobs/<old_job>/* $JENKINS_HOME/jobs/<new_job>/
OLD_BUILD_NO=`cat $JENKINS_HOME/jobs/seed/nextBuildNumber`
NEW_BUILD_NO=`expr $OLD_BUILD_NO - 1`
echo $NEW_BUILD_NO > $JENKINS_HOME/jobs/<new_job>/nextBuildNumber
chown -R jenkins:jenkins $JENKINS_HOME/jobs/temp/
Now run this script as:-
sudo bash script.sh
Although it creates the required job in the same jenkins server instance, the basic idea is same ..to populate the nextBuildNumber file.
The accepted answer to modify the nextBuildNumber File sadly didn't work for me, but found this answer by jayan in another Stackoverflow question:
https://stackoverflow.com/a/34951963
Try running below script in Jenkins Script Console.. Change "workFlow" to your
Jobname
def job = Jenkins.instance.getItem("workFlow")
job.nextBuildNumber = 10
job.saveNextBuildNumber()
Jenkins HockeyApp plugin can automatically create reasonably nicely formatted release notes from git changes. However, this does not seem to work if HockeyApp upload is done in promotion phase, using promotion plugin. In that case the change log is empty.
This can be partially solved by selecting "Load Release Notes from File" and giving path to changelog.xml in the project (../builds/${PROMOTED_NUMBER}/changelog.xml), but the output is not as clean as it is with the "Use Change Log" selection, containing also the file names and commit id's.
What is the best way to automatically create nicely formatted logs for HockeyApp transfer, when the transfer happens in promotion phase and possibly on a Jenkins slave machine?
Answering to myself: It is possible to get the change log from jenkins master to jenkins slave
and parsing the obtained changelog.xml to more user readable by using this simple script:
#!/bin/bash
PROJECT_NAME="$1"
BUILD_NUMBER="$2"
BUILD_DATE="$3"
CHANGELOG=changelog.xml
echo "project=${PROJECT_NAME} build=${BUILD_NUMBER}"
PROJECT_NAME=`basename ${PROJECT_NAME}`
curl ${PROMOTED_URL}api/xml?xpath=/*/changeSet/item/comment\&wrapper=changelog > ${CHANGELOG}
PARSEDLOG=`sed -e 's/<\/[^>]*>/€€/g' ${CHANGELOG} | sed -e 's/<[^>]*>/- /g' | tr €€, '\r' | sed '/^ \s*$/d'`
echo "${PROJECT_NAME} ${BUILD_NUMBER} ${BUILD_DATE} change log:
=====================================================================
${PARSEDLOG}" > changelog.txt
I know there are much better and reliable ways to clean up the xml than the sequence of sed and tr commands I have used, but this works for now.
Is there a way to have a script being run from an execute shell step access the build status as well as other information about the build? (e.g. build number, start/end time, etc)
I need to update a wiki page with a script with the information about the build.
Thanks in advance!
Build status information gets saved into simple XML files. Take a look at
{jenkins-directory}/jobs/{job-name}/builds/{build-number}/build.xml. You can use symbolic links like lastSuccessfulBuild instead of specifying a build number if you want.
You'll find all information about the build there: build status, start time, duration, etc. Parse the XML file or just use grep in a bash script.
If you don't want to use the filesystem you can use Jenkins API.
But in any case, once you got a script that can determine build parameters and update your wiki page, you can put it into another Jenkins job and trigger it automatically (for example, with the BuildResultTrigger Plugin).
I'm using jenkins own API to get the build status while the job is running, which works like a charm. Be aware that i'm using JQ To parse the json response.
To get this to work simply add a shell script and execute the following command: BUILD_STATUS=$(curl --silent ${BUILD_URL}api/json | jq -r '.result')
Which results in the following:
While executing a build, Jenkins set environment variables you can use in your script.
also refer to the detailes on how to use it -
%VAR% in batch files and $VAR from inside the Jenkins job configuration page
I'm planning to write a script that would choose a set of Jenkins jobs with a regexp, start their builds and wait until they finish. If most of them fail, I want to change some global env vars (I already know how to do this) and build them again. Then I want to collect the test results and format it into a nice report.
I can't put this into the individual jobs' post-build actions, I need info about all of them to write the report and to do the rebuilding.
My current idea is to use the Jenkins REST API, but before I do so: is this already implemented somewhere?
Give a look at Multi-Job plugin and see if it fits your requirement.
Else go with REST API.
Because unique requirement of our build process I had to use jenkins cli :
java -jar jenkins-cli.jar -s http://<jenkinsURL> build <job-name> -s <parameters if any>
The trailing -s makes it wait till the job is complete.
I have a bash script that looks like this:
#!/bin/sh
previousRelease=`git describe --tags --match "release*" origin/release`
git diff --name-status $previousRelease..origin/release
Is there a way of having Jenkins execute it as part of a build process? The intention is to see a list of files that have changed since the last release, as a manual step to confirm that the release should go up. The user who has triggered the build needs to read the output and then confirm the release should go ahead.
Most things are possible to do in Jenkins but if it is the best way of doing it is another question.
To solve this I would use an approach with two jobs one for checking the diff (hock that one on to the git repository) The other job for doing the actual release.
The check diff job
1 Create a job of the type freestyle project with build type "execute shell" and run your script above. Add some prints at the end of the log to create a clickable link to manually start the release job with current git-id as argument.
Just printing an URL in console output will make it clickable so:
export GITID=`git log -n| grep and sed or awk something`
echo http://jenkins.example.com:8888/job/releaseme/buildWithParameters?label=$GITID¶meters=build
will create the accept changes user interface you requested.
The release job
2 Create another job(above I assumed you named it releaseme) let the job have one parameter as argument (tick "This build is parameterized") make let the argument be the git-id you would like to release. Create your release script in this job.