Upstream Jobs, Downstream Jobs, and Input

Scenario: Six chained jobs run, but nobody can identify which tested artifact reached the final environment.

Pipeline example

stage('Promote') { input { message 'Promote tested digest?' }; steps { build job: 'deploy', parameters: [string(name: 'DIGEST', value: env.DIGEST)] } }

Pass artifact identity across jobs

The build step can invoke another job, pass typed parameters, wait, and propagate its result. Upstream/downstream links explain orchestration but not which bytes moved. Pass source SHA, immutable artifact digest, originating build URL, and target environment. The downstream job retrieves exactly that package and verifies its checksum instead of rebuilding a mutable branch.

Long chains hide coupling in credentials, defaults, retention, and result thresholds. One Pipeline gives unified visualization when stages share ownership and lifecycle. Separate jobs make sense at permission, team, or reusable deployment-service boundaries. Document the interface, prevent recursive triggers, and determine whether a timeout can leave the downstream operation running.

Input is a controlled transition

The input step pauses for a person, can restrict submitters, and records the response. Wrap it in timeout and place it before allocating scarce deployment agents. Approval should bind approver, environment, policy evidence, and digest. Authority to click Proceed must not permit substitution of untested bytes.

Test abort, timeout, controller restart, duplicate click, and a downstream failure after acceptance. Ensure external locks expire and partial operations are idempotent. A rejected promotion should leave the tested package available for a later authorized attempt while preserving that it was never released.

Goal: Practice the concrete behavior in jenkins-parameterized-deploy. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.