Detailed overview of Jenkins Jobs

In previous articles of this series, we have already seen in detail,

• Steps to install Jenkins on Windows/MacOS/Ubuntu/Containers
• What is a Jenkins Job?
• What different types of Jobs?
• Also how to configure a job on Jenkins.

In case you have missed reading all articles in this series and you wish to read right from start you can click here

In today’s article we are going to deep dive into Jenkins jobs. We will try to understand in detail few topics (listed below) which can make our Jenkins setup more powerful.

• Way to configure a Job using 3rd party tools.
• We will also look at some settings to optimise build process outputs.
• Easy way to access build outputs.
• How to create jobs which take dynamic input?
• How to create jobs that run automatically and follow a schedule?

So, let’s begin! 🤓💡

Using Global build tool to configure a job

Jenkins+Maven

• Install Git (refer to this article for more details on installation)
• You will need to configure Maven as a global build tool.
  - In the Jenkins web interface, go to:
  Manage Jenkins -> Global Tool Configuration -> Maven installations -> Add Maven.
  - Give your Maven installation a name and check the option to Install automatically.

Sample job “Hello Maven” that runs a JAVA application from repo.

• We will add GitHub link to JAVA application repo in SourceCode management section (to learn more on detail step to configuration refer to this article)
• Make sure you select appropriate branch to avoid build failure by default it is master.
• Now in “Build” section, we need to add build step to call Maven.
• We select Maven version & goal of our build

Select option “Invoke top-level Maven targets” from Add build step select box

• One more build step to be added under “Execute shell” option, a JAVA command that will run code that Maven builds.

java -cp target/hello-1.0-SNAPSHOT.jar com.learningjenkins.App

• Job is now configured let’s save & run the job.
• Once build completes, we can check the console output
  - It shows, Jenkins fetched source code from specified repo
  - For 1st time Jenkins will download & install Maven on your local system.

Optimal use of “WorkSpace”?

• Each and every job is given dedicated directory on Jenkins server call “WorkSpace”
• This is where job stores any files that are generated during build.

WorkSpace for “Hello-Maven” job, shows files & directories that got checked out from GitHub at beginning of Build

• As every build uses same WorkSpace, it is advisable to cleanup before next build. “Wipe Out Current WorkSpace” in left menu will do remove all the files & directories from WorkSpace.
• To automatically cleanup WorkSpace before each build, you can select “Delete WorkSpace before build starts” option from Build Environment tab. (for more details click here)
• You also automate cleanup after build completes, with a Post Build action and select, “Delete WorkSpace when build is done” option.

Manage Artifacts

• Most Jenkins job will generate a product at the end of each build.
• It could be compiled “executable / archive file / text report” ( *.exe / *.jar / *.txt) . These products are known as “Artifacts”

Console Output of “Hello-Maven” — There is line labelled building jar, with path to jar file

• It will be waste of time, if we have to manually look through workspace and find artifacts instead, we could configure a Post-Build action and select “archive the artifacts” option.

Artifacts to archived

• Here we can specify absolute path or wildcard “**” to files that we want to archive for successful builds.

There will be direct link to Artifacts on project screen when build completes.

One solution to multiple problems

Main objective on automation is to create one solution to multiple situations.

• Most easy way to to achieve above objective is to create “scripts” that accept parameters. Jenkins allows to create a job that accept different parameters including strings, boolean & multiple choice as well.

Job that accepts parameters

• These values are injected into the job and accessed as “environment variables”
• We use all uppercase letters for parameter names. They are case sensitive on Mac/Linux/Docker and not on Windows system.
• Good practice to avoid spaces & special characters in parameter names. Better to use single word or multiple words separated by underscore.

%Name% for Windows and $Name for Mac/Linux/Container

• Link “the list of available variables” shows additional parameters that automatically created by Jenkins and can be pulled into job.
• Frequently used parameters are BUILD_NUMBER(current build number) and BUILD_ID(current build ID, identical to BUILD_NUMBER for builds created in Jenkins versions 1.597+ but, YYYY-MM-DD_hh-mm-ss timestamp for older builds). These variables are used for creating tags or names for artifacts produced by builds.

• Steps to configure a job that takes “string” parameters

String parameter “VERSION_NUMBER” with default value 1.0.0. We ask user to version number as i/p to this job

We add a script to display version number

# Bash Script for Windows system
@echo off
@echo VERSION_NUMBER = %VERSION_NUMBER%

Build link now changes to “Build with Parameters” for this job

In console o/p you can see the version number once job completes build.

• Steps to configure a job that takes “multiple choice” parameters

Create multiple choice parameter job under General Tab. Parameter is “Environment” with possible values, Development, Staging and Production

We add a script to display selected environment value in Build step

# Bash Script for Windows system
@echo off
@echo ENVIRONMENT = %ENVIRONMENT%

1st option is default value, others can be selected from select i/p

Console o/p displays value of Environment variable selected on build completion.

• Steps to configure a job that takes boolean parameters

Boolean parameter RUN_TESTS, default value checkbox is unchecked means it is false by default

When above script executes, depending on value of RUN_TESTS parameter we display message in build o/p

# Bash Script for Windows system
@echo OFF
echo "RUN_TESTS = %RUN_TESTS%"
if "%RUN_TESTS%"=="true" (
    echo "RUNNING TESTS!"
) else (
    echo "No tests will be run"
)

You can choose the value of parameter to be true/false

As we left RUN_TESTS unchecked, hence its value is false, so our o/p is “No tests will be run”

Special mention of “Scheduled Jobs”

• Till now we have triggered all our jobs manually but sometimes we need to run a job automatically.
• We can run jobs on automatic schedule, which can help in automating tasks like:
  - Update software
  - Checking system health
  - Downloading and processing data.
• Jenkins uses format similar to cron(time based scheduler in UNIX OS) for scheduling jobs.
• Execution times are defined by expression representing schedule for running the jobs.

From left to right above values are added Jenkins scheduler

• To represent all values we use “*” value for the field, for eg: if we put, * for day field it means schedule will be valid for all the days of week.

Jenkins validate the expression and offers suggestion to use “H” for 1st field.

• Using “H” for field value instead of * or a specific value, lets Jenkins schedule a job close when we want to run it. That way if multiple jobs are scheduled at same time, Jenkins can spread them automatically w/o missing the schedule. In short, using “H” lets us cut Jenkins some slack.
• Jenkins provides aliases for general time, like: @hourly, @daily, @weekly, @monthly, @midnight, (anytime between 12am to 3am) etc so we can give Jenkins general time frame that we want the job to run.

“started by timer” means Jenkins followed exact schedule as configured

• Timezones are relative to server’s timezone where Jenkins is setup. Most probably UTC time zone. When scheduling job consider timezone difference.

Conclusion

• A job is a runnable task that Jenkins controls to achieve a required objective.
• We need to configure our jobs according to our requirements for making it fully runnable.
• We can also trigger our build either through GitHub hookup or build periodically or Poll SCM or trigger build remotely. These are the most common methods that we use in the IT world.
• Lastly, another job can automatically trigger through the Post-build action in Jenkins.