Types of Jenkins Jobs

Jenkins supports multiple job types.

Freestyle Project

A simple, click-based job.

Best suited for:

  • Running test scripts
  • Basic automation tasks

Pipeline

A code-based job using a Jenkinsfile.

Ideal for:

  • Complex CI/CD workflows
  • Automation pipelines

Multibranch Pipeline

Automatically detects and builds multiple Git branches.

Folder

Used to organize related Jenkins jobs and pipelines.

Interview Line

"Jenkins supports multiple job types. Freestyle jobs are simple and good for basic tasks; Pipeline jobs are more advanced and support CI/CD through code; there are also Multibranch Pipelines for building multiple Git branches."

Advertisement

Freestyle vs Pipeline

The key distinction:

Clicking = Freestyle

Writing Steps as Code = Pipeline

Freestyle Project

A Jenkins job configured using the GUI.

Advantages:

  • Easy to create
  • Easy to understand

Limitation:

  • Hard to maintain

Pipeline

A Jenkins job defined using Pipeline as Code through a Jenkinsfile.

Advantages:

  • Scalable
  • Reusable
  • Supports complex automation workflows
  • Version controlled in Git
  • Supports parallel test execution

Why It Matters for Testers

  • Freestyle jobs are easy but difficult to maintain.
  • Pipelines are scalable and reusable.
  • Pipeline code can be stored in Git.
  • Pipelines support parallel execution.

Real Project Recommendation

Pipeline is preferred in real projects.

A Freestyle job is configured completely through the Jenkins UI.

A Pipeline job is created by defining a Jenkinsfile in Git with stages (see Jenkins Pipelines & Jenkinsfile).

Configuring a Jenkins Job

Configuring a Jenkins job means defining the settings and execution steps that Jenkins performs.

General

Defines:

  • Job Name
  • Description

Source Code Management

Defines:

  • Git Configuration

Build Triggers

Defines:

  • When the job executes

Build Steps / Stages

Defines:

  • What Jenkins executes

Post-Build Actions

Defines:

Interview Line

"Configuring a Jenkins job involves defining source-code details, build steps, triggers, and post-build actions. In my project, I configured build steps, integrated Selenium and API tests, set up triggers, and published reports."

Triggering a Job Manually

Manually triggering a Jenkins job means starting the job yourself instead of relying on automatic triggers.

Manual execution provides full control and is useful for:

  • Re-running jobs
  • On-demand execution

Build Now

One-click execution.

Typically used for:

  • Freestyle Jobs

Build with Parameters

Run a parameterized job using custom inputs.

Build Triggers

Build triggers determine when Jenkins starts a job.

Purpose

Triggers automatically start builds based on specific conditions or events.

A good analogy is a school bell.

Manual Trigger

User clicks:

  • Build Now

SCM Polling

Jenkins periodically checks Git repositories for changes.

Git Webhook

Git automatically notifies Jenkins whenever code is pushed.

Scheduled (CRON)

Runs jobs according to a predefined schedule.

(See Jenkins Scheduling: CRON, Poll SCM & Webhooks.)

Upstream Job Completion

One completed job automatically triggers another job.

Note

A single Jenkins job can use multiple triggers.

Example:

  • Git Webhook
  • Manual Trigger

Build with Parameters

Build with Parameters allows Jenkins jobs to execute using custom input values instead of fixed values.

Parameters are supplied when the job is triggered.

Common Parameter Types

  • String
  • Choice
  • Boolean

Example

Select:

  • Browser
  • Environment

before executing a Selenium automation suite.

Re-run a Failed Build

Use:

  • Build Now
  • Rebuild (provided by the Rebuilder plugin)

Stop a Running Job

Use:

  • Red Stop Button
  • Abort

From Freestyle to Pipeline: The Same Job Both Ways

Every Freestyle setting has a Pipeline equivalent — which is why most teams migrate once jobs grow:

Freestyle screen sectionJenkinsfile equivalent
General → "This project is parameterized"parameters { … }
Source Code Management → Gitcheckout scm (automatic in a Pipeline-from-SCM job)
Build Triggers → Build periodically / Poll SCMtriggers { cron(…) ; pollSCM(…) }
Build Environment → Abort if stuckoptions { timeout(…) }
Build Steps → Invoke top-level Maven targetsstage('Test') { steps { sh 'mvn …' } }
Post-build Actions → Publish JUnit, Archive artifacts, E-mailpost { always { junit …; archiveArtifacts … } failure { mail … } }
 
// Jenkinsfile — the Selenium regression job as code
pipeline {
  agent any
  parameters {
    choice(name: 'BROWSER', choices: ['chrome', 'firefox', 'edge'], description: 'Browser to run')
    choice(name: 'SUITE', choices: ['smoke', 'regression'], description: 'TestNG group')
  }
  triggers {
    cron('H 2 * * 1-5')                 // nightly on weekdays
  }
  options {
    timeout(time: 60, unit: 'MINUTES')  // abort hung runs
    buildDiscarder(logRotator(numToKeepStr: '30'))
  }
  stages {
    stage('Test') {
      steps {
        sh "mvn -B clean test -Dbrowser=${params.BROWSER} -Dgroups=${params.SUITE} -Dheadless=true"
      }
    }
  }
  post {
    always {
      junit 'target/surefire-reports/*.xml'
      archiveArtifacts artifacts: 'target/screenshots/**, target/reports/**', allowEmptyArchive: true
    }
    failure {
      mail to: 'qa-team@example.com',
           subject: "FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
           body: "Report: ${env.BUILD_URL}"
    }
  }
}

Commit this file to the root of the test repository, create a Pipeline job with "Pipeline script from SCM", and the whole configuration is now reviewed, versioned and reproducible — if the Jenkins server is rebuilt, the job comes back from Git. Use the Pipeline Syntax link in any pipeline job to generate snippets, and "Replay" to try changes without committing. Full guide: Jenkins Pipelines & Jenkinsfile.

Running browsers inside Jenkins agents usually means containers — see how to set up Selenium Grid with Docker for CI in the Docker + Selenium Grid Guide.

From Real Projects

In my projects I ran Selenium and TestNG suites in batch, group, parallel and cross-browser mode. A CI server like Jenkins is the natural next step: the same suites, triggered automatically after each build or on a schedule, with results published for the whole team. On Canolog, the many forms and screens across sales, inventory, finance and service are where keeping page details in POM classes and reusable steps in a business library paid off. Keep the job configuration in a Jenkinsfile so it's reviewed like code.

📖 Related tutorials

📚 Official documentation: Jenkins documentation

FAQs

What Are the Main Jenkins Job Types?

Jenkins supports:

  • Freestyle Project
  • Pipeline
  • Multibranch Pipeline
  • Folder

What Is the Difference Between Freestyle and Pipeline?

Freestyle

  • GUI-Based Configuration
  • Easy to Create
  • Hard to Maintain

Pipeline

  • Jenkinsfile
  • Pipeline as Code
  • Scalable
  • Reusable
  • Stored in Git
  • Supports Parallel Execution

Pipeline is preferred for real-world projects.

What Sections Are Included in Jenkins Job Configuration?

A Jenkins job configuration includes:

  • General
  • Source Code Management
  • Build Triggers
  • Build Steps / Stages
  • Post-Build Actions

How Do You Trigger a Jenkins Job Manually?

Use:

  • Build Now
  • Build with Parameters

What Are Build Triggers?

Build triggers automatically start Jenkins jobs based on:

  • Manual Execution
  • SCM Polling
  • Git Webhooks
  • Scheduled (CRON)
  • Upstream Job Completion

A single job can use multiple triggers.

What Is Build with Parameters?

Build with Parameters allows custom input values such as:

  • String Parameters
  • Choice Parameters
  • Boolean Parameters

Example:

  • Browser Selection
  • Environment Selection

before executing automation tests.