Multibranch Pipeline Lab

Source: Dev.to

Why multibranch is important (DevOps reason)

With a normal Jenkins job you usually build one branch, and webhooks often don’t map cleanly to “which branch/job”.

Multibranch Pipeline automatically:

• discovers branches in GitHub
• builds the right branch automatically
• creates a job per branch (in one place)
• supports PR workflows (real‑team CI)
• removes the “click Build Now” step

In production, DevOps wants CI per branch/PR, not only on main.

What branches do we use in real companies?

Most common production patterns

Pattern A (simplest, common)

main          → production‑ready
feature/*     → developer work
PR → merge to main

Pattern B (with release stability)

main          → production
develop       → integration / staging
feature/*     → PR to develop
release       → merge to main

For beginners, use Pattern A.

Do you have to create more branches?

✅ Yes – at least one feature branch, because multibranch is meant to build more than one branch automatically.

You will create:

• main
• feature/hello-ci

That’s enough.

PART 1 – Create the GitHub repo (with Jenkinsfile)

Step 1 – Create repo

GitHub → New repository

• Name: jenkins-multibranch-lab
• Public or private (either works)

Clone it to your machine.

Step 2 – Create files

Inside the repo:

app.sh

#!/bin/bash
echo "Hello from branch: $(git rev-parse --abbrev-ref HEAD)"
echo "Running on host: $(hostname)"

test.sh

#!/bin/bash
if [ -f app.sh ]; then
  echo "TEST PASSED"
  exit 0
else
  echo "TEST FAILED"
  exit 1
fi

Make them executable:

chmod +x app.sh test.sh

Step 3 – Add Jenkinsfile (branch‑aware)

Create Jenkinsfile in the repo root:

pipeline {
    agent any

    options {
        timestamps()
        disableConcurrentBuilds()
    }

    stages {
        stage('Checkout Info') {
            steps {
                sh '''
                  echo "Branch: ${BRANCH_NAME}"
                  echo "Commit: $(git rev-parse --short HEAD)"
                '''
            }
        }

        stage('Build') {
            steps {
                sh './app.sh'
            }
        }

        stage('Test') {
            steps {
                sh './test.sh'
            }
        }
    }

    post {
        success { echo "CI SUCCESS for ${BRANCH_NAME}" }
        failure { echo "CI FAILED for ${BRANCH_NAME}" }
        always  { cleanWs() }
    }
}

Commit and push to main:

git add .
git commit -m "Add multibranch CI lab"
git push origin main

PART 2 – Create Multibranch Pipeline in Jenkins (UI steps)

Step 4 – Create job

Jenkins Dashboard → New Item

• Name: multibranch-ci-lab
• Type: Multibranch Pipeline → OK

Step 5 – Configure repo source

Branch Sources → Add source → GitHub

• Credentials:

  • Public repo – none needed
  • Private repo – add a GitHub token in Jenkins Credentials first

• Repository HTTPS URL: paste your repo URL.

Step 6 – Build configuration

• Mode: by Jenkinsfile
• Script Path: Jenkinsfile (default)

Step 7 – Branch discovery (important)

Find Behaviors → Discover branches and enable it.
(Optional later) enable “Discover pull requests”.

Beginner‑safe option: build branches normally.

Step 8 – Save and scan

Click Save. Jenkins will start a Scan Multibranch Pipeline, find branches with a Jenkinsfile, and create jobs automatically (e.g., a job for the main branch).

PART 3 – Webhook (so it triggers automatically)

Step 9 – Configure GitHub webhook

GitHub repo → Settings → Webhooks → Add webhook

• Payload URL:

  • If Jenkins is local only – use an ngrok/public URL
  • If Jenkins is internet‑accessible – use that URL

• Content type: application/json

• Events: Just the push event (beginner) – you can add “Pull request” later.

Now a GitHub push will trigger Jenkins scan/build.

PART 4 – Create feature branch (real production workflow)

Step 10 – Create feature branch

git checkout -b feature/hello-ci

Edit app.sh and change the message:

echo "Hello from FEATURE branch"

Commit and push:

git add app.sh
git commit -m "Update app output on feature branch"
git push -u origin feature/hello-ci

What should happen now

1. GitHub sends the webhook.
2. Jenkins multibranch detects the new branch.
3. Jenkins automatically creates a job for feature/hello-ci and runs the CI pipeline – no “Build Now” needed.

PART 5 – Merge to main (how real prod is done)

Step 11 – Open PR

GitHub → Pull Requests → New PR

• Base: main
• Compare: feature/hello-ci

In real teams:

• PR review happens.
• CI must pass before merge (branch protection).

Merge the PR.

Step 12 – What Jenkins does after merge

1. The merge triggers the GitHub webhook.
2. Jenkins runs the pipeline for main.
3. main now contains the updated code and the CI result is displayed.

Why Multibranch Matters

Each branch proves itself before it touches main.

What DevOps Must Pay Attention To (Daily Work)

1) Webhook Health

Pushes not triggering?

• Check Webhook delivery logs in GitHub
• Review Jenkins logs
• Verify the URL (e.g., ngrok may have expired)

2) Branch Discovery Settings

Branch not built?

• Jenkins may not have discovered it
• The branch might lack a Jenkinsfile
• Filters could be excluding it

3) Credentials

Private repo fails checkout?

• GitHub token missing
• Incorrect permissions on the token

4) Agents

If the pipeline uses agent { label 'mac-agent' }

• The agent must be online
• The correct label must exist on the agent

5) Build Stability

• Flaky tests
• Long build times
• Workspace cleanup issues

Why Companies Need Multibranch (Production Answer)

Multibranch enforces:

• CI for every branch (not just main)
• Automated branch‑job creation
• Consistent builds across branches
• PR‑based workflows
• Less manual clicking
• Clear traceability: branch → build → commit

Interview‑Ready Answer

“Multibranch Pipeline is used to automatically build each branch/PR with pipeline‑as‑code, which matches real GitHub workflows and prevents manual job management.”