Setup & Your First Job
From a running Jenkins to a job that builds your code automatically.
With Jenkins running, let’s finish the setup and create a job — the basic unit of work. We’ll start with a freestyle job to learn the moving parts, then you’ll be ready for pipelines.
🎯 Learning Objectives
By the end of this lesson you will:
- Complete the initial Jenkins setup
- Understand the difference between freestyle jobs and pipelines
- Create a job that pulls from Git and runs a build
- Trigger builds automatically on code changes
Finishing Setup
After entering the initial admin password, the setup wizard walks you through:
- Install suggested plugins — a sensible default set (Git, Pipeline, credentials).
- Create an admin user — don’t keep using the initial password.
- Set the Jenkins URL — how Jenkins refers to itself in links and webhooks.
⚠ Secure it before exposing it
Never expose a fresh Jenkins to the internet without authentication and HTTPS. An open Jenkins is a well-known target — attackers use it to run arbitrary builds (i.e. arbitrary code). Lock down security first.
Jobs: Freestyle vs Pipeline
| Type | What it is | Best for |
|---|---|---|
| Freestyle | Configured through the web UI with forms | Simple tasks, learning |
| Pipeline | Defined as code in a Jenkinsfile |
Real projects (versioned, reviewable) |
💡 Freestyle to learn, Pipeline for real
Freestyle jobs are great for understanding the concepts. But production work belongs in a Jenkinsfile committed to your repo — it’s version-controlled, code-reviewed, and reproducible. We’ll build one next lesson.
Creating a Freestyle Job
New Item → Freestyle project. The key sections:
- Source Code Management — point it at your Git repository URL and branch.
- Build Triggers — decide when it runs (poll SCM, webhook, schedule).
- Build Steps — the commands to execute.
A typical build step:
# Execute shell (build step)
echo "Building commit $GIT_COMMIT"
npm ci
npm test
npm run buildTriggering Builds Automatically
You want builds to run when code changes, not only when you click. Two common approaches:
| Trigger | How it works |
|---|---|
| Webhook | Git provider notifies Jenkins instantly on push (preferred) |
| Poll SCM | Jenkins checks the repo on a schedule (e.g. H/5 * * * *) |
💡 Prefer webhooks
Webhooks fire the moment a push happens — instant feedback and no wasted polling. Polling is a fallback for when your Git host can’t reach Jenkins (e.g. behind a firewall).
The H in H/5 * * * * is Jenkins-specific: it spreads load by hashing the job name to pick a consistent-but-staggered minute, instead of every job firing at exactly the same time.
🧪 Hands-on Lab
Create a Build Job
- Create a freestyle job pointing at a Git repository
- Add a shell build step that installs dependencies and runs tests
- Configure it to build on every push (webhook) or every 5 minutes (poll SCM)
🧠 Knowledge Check
What is the main advantage of a Pipeline job over a freestyle job?
Why are webhooks generally preferred over polling SCM for triggering builds?
💼 Interview Preparation
What are important steps to secure a Jenkins instance?
Summary
You’ve completed setup, learned freestyle vs pipeline jobs, created a build job from Git, and set up automatic triggers. Now it’s time to define pipelines as code with a Jenkinsfile.