Detailed overview of Jenkins Jobs
6 min readFeb 8, 2023
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
- 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 toInstall automatically
.
- 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
- 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.
- 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”
- 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.
- Here we can specify absolute path or wildcard “**” to files that we want to archive for successful builds.
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.
- 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.
- 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
# Bash Script for Windows system
@echo off
@echo VERSION_NUMBER = %VERSION_NUMBER%
- Steps to configure a job that takes “multiple choice” parameters
# Bash Script for Windows system
@echo off
@echo ENVIRONMENT = %ENVIRONMENT%
- Steps to configure a job that takes boolean parameters
# 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"
)
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.
- 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.
- 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.
- 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.