Skip to content
Latchkey

Jenkins "Replay" Runs Stale Code - Fix Unexpected Pipeline Behavior

"Replay" re-runs a build with the Jenkinsfile (and library code) captured from the original run, optionally with your inline edits. It does not pull the latest commit, so a fix you pushed to SCM appears to have no effect when you replay an old build.

What this error means

After pushing a Jenkinsfile or shared-library fix, a Replay still fails the old way. The replay used the snapshot from the original build, not your new commit - running the branch fresh would behave differently.

Jenkins behavior
# Replay of build #87 still shows the pre-fix error,
# because Replay edits/uses the script captured at build #87,
# not origin/main HEAD.

Diagnose it: agent, workspace, or sandbox?

Declarative pipeline failures usually come from the environment rather than the script: no matching agent, a dirty reused workspace, or the Groovy sandbox rejecting a method.

Jenkinsfile
// print what the agent actually is
sh 'hostname && whoami && pwd && java -version'
sh 'env | sort | head -40'

// workspaces are REUSED between builds by default
cleanWs()

Common causes

Replay uses the captured script, not the latest SCM

Replay starts from the Jenkinsfile and (optionally) library source captured at the original build. Edits you make in Replay are inline; it does not fetch your newest commit.

Shared library pinned to the original version

A replay reuses the library version resolved by the original build, so a fix pushed to the library branch is not picked up unless you change the version or run fresh.

How to fix it

Run the branch fresh instead of replaying

  1. Trigger a new build (Build Now / scan the branch) so Jenkins checks out the latest commit.
  2. Confirm the run resolved the expected Jenkinsfile and library version from SCM.
  3. Use Replay only for quick inline experiments, not to validate a committed fix.

Edit and override in the Replay form when iterating

If you do want to test a change without committing, edit the script (and library sources) directly in the Replay screen so the replay uses your edits.

How to prevent it

  • Validate committed Jenkinsfile/library fixes with a fresh build, not Replay.
  • Pin library versions explicitly so you know which version a build used.
  • Treat Replay edits as throwaway experiments, not the source of truth.

Frequently asked questions

What causes Jenkins "Replay" runs stale code?
There are 2 common causes: replay uses the captured script, not the latest scm and shared library pinned to the original version. Replay starts from the Jenkinsfile and (optionally) library source captured at the original build.
How do I fix Jenkins "Replay" runs stale code?
There are 2 fixes depending on which cause you have: run the branch fresh instead of replaying and edit and override in the replay form when iterating. Work through them in order, since the first is the most common.
What does Jenkins "Replay" runs stale code actually mean?
After pushing a Jenkinsfile or shared-library fix, a Replay still fails the old way.
How do I stop Jenkins "Replay" runs stale code happening again?
Validate committed Jenkinsfile/library fixes with a fresh build, not Replay. The prevention section lists 3 changes that keep it from recurring.

Related guides

References

Not every red build is your code. Latchkey repairs the ones that are not, on the runner. Start free → 30-day trial · No credit card