Declarative or scripted pipeline?

This generates a declarative pipeline (the `pipeline { agent { ... } stages { ... } }` form), which is what Jenkins itself recommends for new pipelines: it's more structured, easier to read, and has built-in validation. Scripted pipelines (raw Groovy inside a `node {}` block) are more flexible but aren't covered here.

What's the difference between the 'any' and 'docker' agent options?

`agent any` tells Jenkins to run the pipeline on any available executor using whatever tools are already installed on that machine. `agent { docker { image '...' } }` instead runs every stage inside a fresh container from the image you specify, which gives you a clean, reproducible environment without depending on what's installed on the Jenkins node itself.

When does the post block run?

The `always` condition runs after every pipeline run regardless of outcome, `success` runs only if all stages passed, and `failure` runs only if something failed. You can enable any combination; a common pattern is `always` for cleanup/notifications and `failure` for alerting.

Why are my shell commands wrapped in single quotes?

Jenkins declarative pipeline `sh` steps take a Groovy string, and single-quoted strings avoid Groovy's `${...}` interpolation being applied to shell variables like `$HOME`, which is usually what you want for ordinary shell commands.

Jenkins Pipeline Generator - Build a Declarative Jenkinsfile

Overview

Introduction

Declarative Jenkinsfiles have a strict, particular structure, misplace a closing brace or put a `sh` step outside a `steps {}` block and Jenkins rejects the whole pipeline before it runs a single stage.

This tool generates a complete, correctly nested declarative Jenkinsfile from a form, covering the agent, stages, environment variables, and post-build actions most pipelines need.

What Is Jenkins Pipeline Generator?

A form-driven generator for Jenkins declarative pipelines. You choose an agent (any, or a specific Docker image), add one or more stages each containing shell (`sh`) steps, optionally set environment variables, and optionally configure post-build actions.

The output is a complete `pipeline { ... }` block, ready to save as a Jenkinsfile at the root of your repository or paste into a pipeline job's inline script field.

How Jenkins Pipeline Generator Works

Each stage you add becomes its own `stage('name') { steps { sh '...' } }` block, in the order you listed them, and environment variables become key-value entries in a top-level `environment {}` block.

The post-block toggles (success/failure/always) each add their own nested block inside a single `post {}` section, with your shell commands escaped so embedded single quotes don't break the generated Groovy string.

When To Use Jenkins Pipeline Generator

Use it when setting up a new Jenkins pipeline job and you want a syntactically correct Jenkinsfile skeleton instead of debugging Groovy brace-matching by hand.

It's also handy for quickly sketching a multi-stage build/test/deploy pipeline structure before filling in the real shell commands.

Often used alongside GitLab CI Generator, CircleCI Config Generator and Conventional Commit Message Generator.

Features

Advantages

Guarantees correct declarative pipeline structure and brace nesting, the most common source of Jenkinsfile syntax errors.
Supports both bare-metal (`agent any`) and containerized (`agent { docker { ... } }`) execution models.
Lets you enable success, failure, and always post-actions independently, matching how most teams actually use post blocks (notifications, cleanup, alerting).

Limitations

Only generates `sh` steps for stage bodies; it doesn't cover `bat` (Windows), parallel stages, `input` for manual approval, or shared library calls.
Environment variable values are emitted as plain strings, not `credentials()` bindings, so secrets should be wired up manually via Jenkins credentials after generation.

Examples

A Docker-agent pipeline with a Build stage

Input

agent: docker (node:20); stage 'Build' → sh: npm install / npm run build; post success → sh: echo done

Output

pipeline {
    agent {
        docker { image 'node:20' }
    }

    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
    }

    post {
        success {
            sh 'echo done'
        }
    }
}

The Docker agent, stage steps, and enabled post-success block are each rendered as their own nested pipeline block.

Best Practices & Notes

Best Practices

Prefer a Docker agent over `agent any` whenever the build has specific tool version requirements, it keeps the pipeline reproducible across different Jenkins nodes.
Keep each stage focused on one concern (Build, Test, Deploy) rather than combining everything into a single stage, this makes the Jenkins UI's stage view actually useful for debugging.
Use the `always` post condition for cleanup and notifications so they run consistently regardless of whether the pipeline passed or failed.

Developer Notes

The generator emits Groovy using 4-space indentation matching Jenkins' own documentation examples, and every `sh` command has embedded single quotes escaped (`'` → `\'`) since the commands are wrapped in single-quoted Groovy strings to avoid unintended `${}` interpolation of shell variables like `$PATH`. Stage and post blocks are only emitted when they contain content, so an unused post condition produces no empty block.

Jenkins Pipeline Generator Use Cases

Scaffolding a new Jenkinsfile for a repository migrating from a Freestyle Jenkins job
Sketching a build/test/deploy stage structure for a team pipeline review
Producing a working Docker-based Jenkinsfile without hand-writing Groovy nesting

Common Mistakes

Using `agent any` when the build depends on a specific tool version, only to have it behave differently across Jenkins nodes with different installed toolchains.
Putting cleanup logic in a `success` block instead of `always`, so it silently doesn't run when the pipeline fails, exactly when cleanup often matters most.

Tips

Wire environment variable values that are secrets through Jenkins Credentials and `credentials()` after generating, rather than hard-coding them in the Jenkinsfile.

Jenkins Pipeline Generator