Input step for manual approval in Jenkins - Deep Dive

Overview - Input step for manual approval

What is it?

The input step in Jenkins pipelines pauses the automated process and waits for a human to approve or provide input before continuing. It is used to add manual approval points in an otherwise automatic workflow. This helps teams control critical stages like deployments or sensitive changes. Without it, pipelines would run fully automatically without any human checks.

Why it matters

Manual approval ensures safety and control in automated processes, preventing unintended actions like deploying broken code or making risky changes. Without manual approval, mistakes could go live immediately, causing outages or data loss. It balances automation speed with human judgment.

Where it fits

Learners should know basic Jenkins pipeline syntax and stages before using input steps. After mastering input steps, they can explore advanced pipeline controls like parallel stages, scripted pipelines, and automated rollback strategies.

Mental Model

Core Idea

The input step acts like a stop sign in a pipeline, pausing automation until a person says 'go'.

Think of it like...

It's like a traffic light at a busy intersection that stops cars until a traffic officer signals them to proceed safely.

Pipeline Flow:

Start ──▶ Build ──▶ Test ──▶ [Input Step: Wait for Approval] ──▶ Deploy ──▶ End

The input step blocks progress until manual confirmation.

Build-Up - 6 Steps

1

Foundation

Basic Jenkins Pipeline Structure

Concept: Understanding the simple flow of a Jenkins pipeline with stages.

A Jenkins pipeline is a script that defines steps to build, test, and deploy software. It uses stages to organize these steps sequentially. For example: pipeline { agent any stages { stage('Build') { steps { echo 'Building...' } } stage('Test') { steps { echo 'Testing...' } } } }

Result

A pipeline that runs build and test stages one after another, printing messages.

Knowing the basic pipeline structure is essential before adding controls like manual approval.

2

Foundation

What is the Input Step?

Concept: Introducing the input step as a pause point in the pipeline.

The input step pauses the pipeline and waits for a human to approve or provide input. It looks like this: input 'Approve deployment?' This stops the pipeline and shows a prompt in Jenkins UI until someone clicks Proceed or Abort.

Result

Pipeline execution pauses and waits for manual approval before continuing.

Understanding that pipelines can pause for human decisions helps balance automation with control.

3

Intermediate

Adding Manual Approval in Pipeline

🤔Before reading on: do you think the input step blocks the entire Jenkins server or just the current pipeline? Commit to your answer.

Concept: How to add an input step inside a stage to require approval before deployment.

You add the input step inside a stage like this: stage('Deploy') { steps { input message: 'Approve deployment?', ok: 'Deploy' echo 'Deploying now...' } } This pauses only the current pipeline run, not the whole Jenkins server.

Result

The pipeline stops at the Deploy stage until someone approves, then continues to deploy.

Knowing the input step only blocks the current pipeline prevents confusion about Jenkins availability.

4

Intermediate

Customizing Input Step Prompts

🤔Before reading on: can the input step collect typed input from users or only yes/no approval? Commit to your answer.

Concept: Input step can ask for typed input, not just approval buttons.

You can ask users to enter data like this: input message: 'Enter version to deploy', parameters: [string(name: 'VERSION', defaultValue: '1.0', description: 'Version number')] This shows a text box for VERSION input before continuing.

Result

Pipeline pauses and collects user input, which can be used later in the script.

Understanding input parameters expands manual control beyond simple approvals to configurable inputs.

5

Advanced

Handling Input Step Timeout and Abort

🤔Before reading on: do you think the input step waits forever by default or has a timeout? Commit to your answer.

Concept: Input step can be configured with timeout and abort handling to avoid indefinite pauses.

You can add timeout like this: try { timeout(time: 1, unit: 'HOURS') { input 'Approve deployment?' } } catch(err) { echo 'Approval timed out or aborted' currentBuild.result = 'ABORTED' error('Stopping pipeline') } This stops waiting after 1 hour and handles aborts gracefully.

Result

Pipeline does not hang forever; it stops if no approval within timeout or if aborted.

Knowing how to handle timeouts prevents stalled pipelines blocking resources indefinitely.

6

Expert

Security and Permissions with Input Step

🤔Before reading on: do you think anyone with Jenkins access can approve input steps by default? Commit to your answer.

Concept: Input step approvals can be restricted to specific users or groups for security.

You can restrict who can approve like this: input message: 'Approve?', submitter: 'team-leads' Only users in 'team-leads' can approve. Others see the prompt but cannot proceed. This prevents unauthorized approvals in sensitive pipelines.

Result

Only authorized users can approve, improving pipeline security and auditability.

Understanding permission controls on input steps is critical for secure production pipelines.

Under the Hood

When the pipeline reaches an input step, Jenkins pauses the current pipeline execution thread and creates a waiting state. It displays a prompt in the Jenkins UI tied to that pipeline run. Jenkins listens for user interaction on that prompt. Once approved or aborted, Jenkins resumes or stops the pipeline accordingly. Internally, this uses Jenkins' queue and executor management to hold the pipeline without consuming executor resources.

Why designed this way?

The input step was designed to integrate human decisions into automated pipelines without blocking Jenkins resources. By pausing only the pipeline thread and using UI prompts, Jenkins allows safe manual intervention. Alternatives like external approval systems were less integrated and harder to manage. This design balances automation speed with necessary human control.

Pipeline Execution Flow:

[Start] ──▶ [Build Stage] ──▶ [Test Stage] ──▶ [Input Step]
                      │               │               ↓
                      │               │        [Pause & Wait]
                      │               │               ↓
                      │               │        [User Approval]
                      │               │               ↓
                      │               │        [Resume Pipeline]
                      ↓               ↓               ↓
                 [Deploy Stage] ──▶ [End]

Myth Busters - 4 Common Misconceptions

Quick: Does the input step block all Jenkins jobs or just the current pipeline? Commit to yes or no.

Common Belief: The input step blocks the entire Jenkins server, stopping all jobs until approved.

Reality: The input step only pauses the current pipeline run; other jobs continue running normally.

Why it matters: Believing it blocks all jobs causes unnecessary fear of using input steps and limits pipeline design.

Quick: Can anyone with Jenkins access approve an input step by default? Commit to yes or no.

Common Belief: Anyone who can see the pipeline can approve the input step prompt.

Reality: By default, anyone with job access can approve, but you can restrict approval to specific users or groups.

Why it matters: Not knowing about approval restrictions risks unauthorized approvals in sensitive pipelines.

Quick: Does the input step wait forever if no one approves? Commit to yes or no.

Common Belief: The input step always waits forever until someone approves or aborts.

Reality: By default it waits indefinitely, but you can add timeout logic to avoid hanging pipelines.

Why it matters: Ignoring timeouts can cause pipelines to block resources indefinitely, hurting CI/CD throughput.

Quick: Can the input step collect typed user input or only yes/no approval? Commit to yes or no.

Common Belief: Input step only supports simple approval buttons, no data entry.

Reality: Input step supports parameters like strings, booleans, and choices to collect user input.

Why it matters: Missing this limits pipeline flexibility and manual control options.

Expert Zone

1

Input steps do not consume Jenkins executors while waiting, freeing resources for other jobs.

2

Using input step inside parallel branches requires careful design to avoid deadlocks or confusing UI prompts.

3

Input step approval actions are logged and can be audited, but logs must be reviewed proactively for compliance.

When NOT to use

Avoid input steps in fully automated CI pipelines where human intervention slows delivery. Instead, use automated quality gates or feature flags. Also, avoid input steps in high-frequency pipelines where manual approval is impractical.

Production Patterns

In production, input steps are commonly used before deploying to production environments, requiring team lead approval. They are combined with timeout and abort handling to prevent pipeline stalls. Approval restrictions ensure only authorized personnel can proceed. Input parameters collect deployment metadata like version or environment.

Connections

Feature Flags

Alternative approach to manual approval by controlling features at runtime instead of pipeline pause.

Knowing feature flags helps understand how to reduce manual pipeline pauses by shifting control to runtime toggles.

Human-in-the-loop AI Systems

Both integrate human decisions into automated processes for safety and quality.

Understanding manual approval in pipelines parallels how AI systems pause for human review to avoid errors.

Traffic Control Systems

Input step acts like a traffic signal controlling flow, similar to managing vehicle movement safely.

Recognizing this connection clarifies the role of manual approval as a flow control mechanism.

Common Pitfalls

#1 Pipeline hangs forever waiting for approval with no timeout.

Wrong approach:

stage('Deploy') {
steps {
input 'Approve deployment?'
echo 'Deploying...'
}
}

Correct approach:

stage('Deploy') {
steps {
try {
timeout(time: 30, unit: 'MINUTES') {
input 'Approve deployment?'
}
} catch(err) {
echo 'Approval timed out or aborted'
currentBuild.result = 'ABORTED'
error('Stopping pipeline')
}
echo 'Deploying...'
}
}

Root cause:

Not adding timeout causes indefinite waiting, blocking pipeline and wasting resources.

#2 Anyone can approve sensitive deployment steps without restriction.

Wrong approach:

input message: 'Approve?', ok: 'Deploy'

Correct approach:

input message: 'Approve?', ok: 'Deploy', submitter: 'team-leads'

Root cause:

Ignoring submitter restriction risks unauthorized approvals and security breaches.

#3 Trying to use input step outside a pipeline context or in scripted pipeline without proper syntax.

Wrong approach:

input 'Approve deployment?'
// used in freestyle job or outside pipeline block

Correct approach:

pipeline {
agent any
stages {
stage('Approval') {
steps {
input 'Approve deployment?'
}
}
}
}

Root cause:

Input step requires pipeline context; misuse causes errors or ignored steps.

Key Takeaways

The input step pauses a Jenkins pipeline to wait for human approval or input, adding control to automation.

It only blocks the current pipeline run, not the entire Jenkins server, allowing other jobs to continue.

Input steps can collect typed parameters, not just yes/no approvals, increasing flexibility.

Timeouts and submitter restrictions are essential to avoid pipeline hangs and unauthorized approvals.

Proper use of input steps balances automation speed with safety and security in production pipelines.

Practice

1. What is the main purpose of the input step in a Jenkins pipeline?

easy

A. To send email notifications

B. To automatically deploy the application

C. To run tests in parallel

D. To pause the pipeline and wait for manual approval

Solution

1. Step 1: Understand the role of the input step

   The input step is designed to pause the pipeline execution and wait for a user to approve or reject the continuation.

2. Step 2: Compare with other pipeline actions

   Other options like deployment, testing, or notifications are handled by different steps, not input.

3. Final Answer:

   To pause the pipeline and wait for manual approval -> Option D

4. Quick Check:

   Input step = manual pause [OK]

Hint: Input step always waits for user action [OK]

Common Mistakes:

• Confusing input with automated steps
• Thinking input triggers deployment
• Assuming input sends notifications

2. Which of the following is the correct syntax to add a manual approval input step in a Jenkins declarative pipeline?

easy

A. input message: 'Approve deployment?'

B. input('Approve deployment?')

C. input { message: 'Approve deployment?' }

D. input message = 'Approve deployment?'

Solution

1. Step 1: Recall Jenkins input step syntax

   The correct syntax uses the input step with named parameters like message: 'text'.

2. Step 2: Check each option

   input message: 'Approve deployment?' matches the correct syntax. Options A, B, and D use incorrect formats or braces.

3. Final Answer:

   input message: 'Approve deployment?' -> Option A

4. Quick Check:

   Correct input syntax uses named parameters [OK]

Hint: Use named parameters with colon for input step [OK]

Common Mistakes:

• Using parentheses instead of named parameters
• Using braces instead of parentheses
• Assigning message with equals sign

3. Given the following Jenkins scripted pipeline snippet, what will happen when it reaches the input step?

node {
  stage('Build') {
    echo 'Building...'
  }
  stage('Approval') {
    input message: 'Proceed with deployment?'
  }
  stage('Deploy') {
    echo 'Deploying...'
  }
}

medium

A. Pipeline pauses and waits for user approval before deploying

B. Pipeline skips the approval and deploys immediately

C. Pipeline fails with a syntax error

D. Pipeline runs all stages without pause

Solution

1. Step 1: Analyze the input step behavior

   The input step pauses the pipeline and waits for a user to approve before continuing.

2. Step 2: Understand pipeline flow

   After approval, the pipeline proceeds to the Deploy stage. Without approval, it stays paused.

3. Final Answer:

   Pipeline pauses and waits for user approval before deploying -> Option A

4. Quick Check:

   Input step pauses pipeline = Pipeline pauses and waits for user approval before deploying [OK]

Hint: Input step always pauses pipeline until user approves [OK]

Common Mistakes:

• Assuming input step is skipped automatically
• Thinking input causes syntax error
• Believing pipeline runs all stages without pause

4. Identify the error in this Jenkins pipeline snippet that uses an input step:

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        input message: 'Approve test run?'
        echo 'Running tests...'
      }
    }
  }
}

medium

A. The message parameter is missing quotes

B. The input step cannot be used in the Test stage

C. The input step must be inside a script block in declarative pipeline

D. The echo step must come before the input step

Solution

1. Step 1: Understand declarative pipeline input usage

   In declarative pipelines, the input step must be wrapped inside a script block to run scripted steps.

2. Step 2: Check the snippet

   The input step is directly inside steps without script, causing a syntax error.

3. Final Answer:

   The input step must be inside a script block in declarative pipeline -> Option C

4. Quick Check:

   Input in declarative needs script block [OK]

Hint: Wrap input step in script block in declarative pipelines [OK]

Common Mistakes:

• Placing input step directly in steps without script
• Missing quotes around message
• Thinking input can't be used in certain stages

5. You want to add a manual approval step in a Jenkins declarative pipeline that asks the user to confirm deployment with a custom message and a timeout of 1 hour. Which snippet correctly implements this?

hard

A. input message: 'Deploy now?', timeout: 3600

B. script { input message: 'Deploy now?', timeout: 3600 }

C. script { input message: 'Deploy now?', timeout: 60, submitter: 'admin' }

D. script { input message: 'Deploy now?', timeout: 60 }

Solution

1. Step 1: Understand timeout parameter unit

   The timeout parameter for input is in seconds, so 1 hour = 3600 seconds.

2. Step 2: Check declarative pipeline syntax

   Input must be inside a script block in declarative pipelines.

3. Step 3: Evaluate options

   script { input message: 'Deploy now?', timeout: 3600 } correctly uses script block and timeout 3600 seconds. script { input message: 'Deploy now?', timeout: 60 } uses 60 (1 minute), B lacks script block, C adds submitter but timeout is 60 seconds.

4. Final Answer:

   script { input message: 'Deploy now?', timeout: 3600 } -> Option B

5. Quick Check:

   Timeout in seconds + script block = script { input message: 'Deploy now?', timeout: 3600 } [OK]

Hint: Timeout is seconds; use script block in declarative [OK]

Common Mistakes:

• Using timeout in minutes instead of seconds
• Omitting script block in declarative pipeline
• Adding unnecessary parameters