Jenkins is the bread and butter for a developer. In my case, we are doing everything with it. Building our solution, and docker images, provisioning queues and topics on our active mq and doing deployments on Dev, stage and even prod.
As I enjoy the possibilities with Jenkins, the speed and the usability of the GUI is not the strongest part in Jenkins. I am very CLI centric, and try to do as much as possible in my terminal. If I have Tasks repetitive task, I try to create scripts which are doing the work for me.
In our case our Jenkins has a deep hierarchy job structure. And we have not only one Jenkins, we have two instances. On one Jenkins we are managing all our solutions and version promotions for the different environment. The second one handles all the deployments and provisioning tasks.
So, if I want to deploy my solution, I have to trigger the
build pipeline, then the
release pipeline on the first Jenkins.
After that I am able to deploy on
DEV on the second Jenkins. If I want to go on
STAGE, I have to promote a
candidate on the first Jenkins, then switch to the second Jenkins to deploy on
So you can imagine that I have to play a Jenkins ping-pong game.
Luckily one of our Jenkins supports the
jenkins-cli. This is a jar which is provided by Jenkins it selfs. To get your version of the CLI-tool, you can simply downloading it from your Jenkins instance on this page
Jenkins has to permit the access for the CLI. You have to allow JNLP connections in the
global secure settings of your Jenkins instance.
To generate the token, you have to to go to your Jenkins user settings:
The Jenkins CLI needs quite a lot of parameter, so it is recommended to encapsulate the CLI and there parameters.
This scripts based on rofi to provide a fuzzy search over the jobs. After selection it will trigger the job and open the job in the browser.
for the token it is recommended to use a password store. In my case I am using pass. It is a lightweight encrypted password manager for Linux. But for testing purposes, a file is also okay for the beginning.
#!/bin/bash JENKINS_URL="http://url.to.jenins" # this is only for testing. this file contains just one line with [loginname]:[token] # in general credencials should be not laying around in cleartext # JENKINS_AUTH="$(cat $HOME/dotfiles/.jenkins.cli.secret)" username=$(pass show [path/to/store] | tail -n1) token=$(pass show [path/to/store] | head -n1) JENKINS_AUTH="$username:$token" JENKINS_JAR="$HOME/.local/bin/jenkins-cli.jar" JENKINS_CLI="java -jar $JENKINS_JAR -auth $JENKINS_AUTH -s $JENKINS_URL" # check date of file if older 7 days if [ "$(find '/tmp/jenkinsJobList' -ctime +7)" ]; then echo "fetch joblist" $JENKINS_CLI list-jobs > /tmp/jenkinsJobList fi # job selection via fuzzy search job=$(cat /tmp/empty /tmp/jenkinsJobList | rofi -dmenu) # triggering the job $JENKINS_CLI build $job # opens the pipeline in browser alternative you can replace it with your browser qutebrowser "$JENKINS_URL/job/$job"
In additional, I have to consider which branch I want to build. We have a very consistent way to name our jobs. So if I want to build our solution and not to promote a solution I just triggering the master branch of a job which contains
BUILD in the job name. All the other does not containing branches.
This part is replacing the lower part of the script.
if [ "$job" != "" ]; then # jobname contains BUILD in the string if [[ "$job" == *"BUILD"* ]]; then jobname="$job/master" link="$JENKINS_URL/job/$job/job/master/" else jobname="$job" link="$JENKINS_URL/job/$job/" fi #trigger job $JENKINS_EXEC -webSocket -auth $JENKINS_AUTH -s $JENKINS_URL build $jobname #open job in browser qutebrowser "$link" fi
Top comments (0)