Jenkins / Evidence, reuse, and authority / Lesson 11

when conditions and bounded human decisions

Use selection and approval for different purposes while keeping candidate identity stable.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain condition ordering relative to agent allocation and input.
Bind a human decision to candidate, target, and relevant evidence.

A condition selects work, not authority

Declarative when can select a stage based on branch context, environment, expressions, and other supported conditions. That answers whether the stage is eligible under its definition, not whether a person is authorized for an external operation. Parcel’s branch name may help choose validation but cannot by itself authorize production. Some conditions require a multibranch context or plugin behavior. Review the effective source and types. A string expression returning false text can behave differently from a boolean false, so make return values deliberate.

Allocation and input ordering affect resources

By default and under specific options, condition evaluation, stage options, input, and agent allocation occur at documented points. beforeAgent, beforeInput, and beforeOptions can change relevant ordering and have documented precedence. This matters when a stage otherwise holds an executor while waiting for a decision or allocates a node only to skip work. Read the actual syntax reference rather than guessing from visual block order. A timeout may also include allocation differently depending on whether it applies at the Pipeline or stage level.

Select before allocating when appropriate

The fragment below evaluates a declared boolean request before stage agent allocation. The branch still needs an enclosing Pipeline and a configured parameter, and its echo performs no release. It illustrates resource-aware selection, not a complete approval design. A true request means someone asked for review; it does not establish trusted source, verified candidate, permitted target, or an authorized decision. Keep those facts independent so a user-editable parameter cannot turn a selection expression into a privilege grant.

groovy A condition-order illustration

stage("Review request") {
    when {
        beforeAgent true
        expression { params.REQUEST_REVIEW == true }
    }
    agent { label "parcel-lab" }
    steps { echo "A separate authorized decision is still required" }
}

REQUEST_REVIEW and the agent label are synthetic prerequisites. No input prompt, approval, allocation, or job execution occurs. The example does not imply that every when condition can run without a workspace.

A human prompt needs a bounded question

The input step or Declarative input directive can pause for a decision under configured permissions and submitter constraints. The real installation’s authorization and bypass behavior must be reviewed. Ask about a specific candidate, configuration, target, and evidence rather than an unknown future latest package. Bound waiting and define rejection, expiry, abort, and changed-input handling. Avoid unnecessarily retaining scarce execution resources during long decisions. An approval is a recorded judgment within scope, not a permanent assertion that later vulnerabilities or incompatible state no longer matter.

Reject a decision for different bytes

The complete local model compares a synthetic approval record with a release request and requires an accepted decision. It rejects an approval naming another candidate. It does not authenticate a Jenkins user, implement the input step, or enforce submitter permissions. In real orchestration, decision records must come from trusted control-plane evidence and material changes need the policy’s re-evaluation behavior. A boolean inside a package manifest cannot approve itself. Keep the identity relationship visible even when the Pipeline provides a convenient manual button.

python Model decision-to-request identity

request = {"candidate": "parcel-lab-r5", "target": "staging"}
approval = {"candidate": "parcel-lab-r4", "target": "staging", "accepted": True}
matched = all(approval.get(k) == v for k, v in request.items())
print(matched and approval["accepted"])
approval["candidate"] = "parcel-lab-r5"
print(all(approval.get(k) == v for k, v in request.items()) and approval["accepted"])

Expected output

False
True

Only declared dictionaries are compared. The accepted field is teaching data, not real authorization or a created Jenkins approval.

Common errors and fixes

A branch condition is treated as authenticated release approval.

Why it happens: Selection context was confused with authority.
How to fix it: Require the independent trusted candidate and target decision.
Prevent it next time: Document conditions and approval controls separately.

A long input wait unnecessarily occupies a build executor.

Why it happens: Decision placement and allocation scope were not reviewed.
How to fix it: Choose an appropriate stage structure and ordering with the owner.
Prevent it next time: Review waiting time, agent use, and timeout scope together.

An earlier approval authorizes a changed candidate.

Why it happens: The decision is bound to a job label rather than immutable request inputs.
How to fix it: Reevaluate material changes and retain the actual approved identity.
Prevent it next time: Test wrong-candidate, expired, rejected, and aborted cases.

Check your understanding

1. Why might beforeAgent help an optional validation stage?

Show worked solution

A condition that can be evaluated without workspace state can skip unnecessary allocation. Confirm the condition’s data availability and supported ordering first. It does not make workspace-dependent checks magically available before a node exists.

2. A reviewer approves r4, but the waiting job later resolves latest as r5. Is that the same decision?