Jenkinsfile Structure and Syntax

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

A Jenkinsfile is a text file defining a Jenkins pipeline as code, stored in source control. Declarative syntax uses a structured pipeline {} block with built-in validation. Scripted syntax uses Groovy node {} blocks for maximum flexibility. Declarative is preferred for most use cases.

Interview Answer2 min

A declarative Jenkinsfile follows a fixed structure where each section has a defined purpose — agent controls where, environment controls what, stages controls when, and post handles cleanup and notifications. Understanding this structure lets you read any Jenkinsfile without confusion.

The mandatory sections

agent at the pipeline level is mandatory — agent any runs on any available agent; agent none defers agent selection to each stage, which is useful when different stages need different Docker images or different machine types
stages contains the ordered list of stage blocks; stages are sequential by default — parallel inside a stage runs multiple nested stages concurrently (run unit tests and static analysis in parallel to save time)
post runs after all stages and has named conditions: always (cleanup, publish test results), success (notify Slack), failure (send alert), unstable (build passed but tests failed) — the always block is where you always put junit result publication and workspace cleanup

Environment and parameters

environment { IMAGE_TAG = "${BUILD_NUMBER}" } creates an environment variable available in all stages and steps as ${IMAGE_TAG} (shell) or env.IMAGE_TAG (Groovy); pipeline-level environment variables are the correct place for values shared across stages
parameters { string(name: 'TARGET_ENV', defaultValue: 'staging') } creates a build parameter; ${params.TARGET_ENV} references it in steps — parameterized builds let you trigger the same pipeline for different environments without separate Jenkinsfiles

Options and tools

options { timeout(time: 30, unit: 'MINUTES') } prevents hung builds from consuming an agent indefinitely — every pipeline should have a timeout
tools { maven 'Maven 3.9' } auto-installs the named Maven version configured in Jenkins global tool configuration; this approach avoids baking Maven into the agent image
script {} inside a stage allows imperative Groovy when declarative constraints are too rigid — use sparingly; excessive script {} blocks are a sign the pipeline should be refactored into shared library functions

Interview-ready guide

Interview answer

The mandatory sections

agent at the pipeline level is mandatory — agent any runs on any available agent; agent none defers agent selection to each stage, which is useful when different stages need different Docker images or different machine types
stages contains the ordered list of stage blocks; stages are sequential by default — parallel inside a stage runs multiple nested stages concurrently (run unit tests and static analysis in parallel to save time)
post runs after all stages and has named conditions: always (cleanup, publish test results), success (notify Slack), failure (send alert), unstable (build passed but tests failed) — the always block is where you always put junit result publication and workspace cleanup

Environment and parameters

environment { IMAGE_TAG = "${BUILD_NUMBER}" } creates an environment variable available in all stages and steps as ${IMAGE_TAG} (shell) or env.IMAGE_TAG (Groovy); pipeline-level environment variables are the correct place for values shared across stages
parameters { string(name: 'TARGET_ENV', defaultValue: 'staging') } creates a build parameter; ${params.TARGET_ENV} references it in steps — parameterized builds let you trigger the same pipeline for different environments without separate Jenkinsfiles

Options and tools

options { timeout(time: 30, unit: 'MINUTES') } prevents hung builds from consuming an agent indefinitely — every pipeline should have a timeout
tools { maven 'Maven 3.9' } auto-installs the named Maven version configured in Jenkins global tool configuration; this approach avoids baking Maven into the agent image
script {} inside a stage allows imperative Groovy when declarative constraints are too rigid — use sparingly; excessive script {} blocks are a sign the pipeline should be refactored into shared library functions

03 · Deep dive