Skip to content

fix: default ssh-agent timeout when loading legacy job configuration - #300

Merged
ogulcanaydogan merged 1 commit into
masterfrom
fix/timeout-zero-legacy-config
Aug 8, 2026
Merged

fix: default ssh-agent timeout when loading legacy job configuration#300
ogulcanaydogan merged 1 commit into
masterfrom
fix/timeout-zero-legacy-config

Conversation

@ogulcanaydogan

Copy link
Copy Markdown
Contributor

Fixes #299.

Job configurations saved before the ssh-agent command timeout became configurable have no persisted timeout value. That deserializes to zero, so ssh-add failed immediately with Timeout after 0 minutes and existing jobs broke after updating to 416.

This falls back to the default timeout whenever a non-positive value is seen:

  • at the point of use in ExecRemoteAgent
  • in the SSHAgentBuildWrapper constructor, so the config form cannot persist 0
  • by migrating legacy SSHAgentBuildWrapper data in readResolve, so existing jobs load and can be reconfigured

Testing: added SSHAgentBuildWrapperTimeoutTest covering the constructor fallback and deserialization of a legacy config that has no timeout element.

Job configurations saved before the ssh-agent command timeout became
configurable have no persisted timeout, which deserializes to zero and
made ssh-add fail immediately with "Timeout after 0 minutes".

Fall back to the default timeout when a non-positive value is seen: at
the point of use in ExecRemoteAgent, in the build wrapper constructor,
and by migrating legacy SSHAgentBuildWrapper data in readResolve.

Signed-off-by: Ogulcan Aydogan <[email protected]>
@ogulcanaydogan
ogulcanaydogan requested a review from a team as a code owner August 8, 2026 22:34
@ogulcanaydogan
ogulcanaydogan merged commit 1d50bf2 into master Aug 8, 2026
19 checks passed
@ogulcanaydogan
ogulcanaydogan deleted the fix/timeout-zero-legacy-config branch August 8, 2026 22:45
MarkEWaite pushed a commit to jenkinsci/bom that referenced this pull request Aug 9, 2026
…7230)" (#7232)

Rolling back to 402.vc9cec9230d4b_ for the same reason as #7205 and #7210:
SSHAgentStepWorkflowTest.teardownDoesNotFailBuildWhenAgentAlreadyStopped
still fails under PCT.

417 could not have fixed it. The 416..417 diff is a single commit, "fix:
default ssh-agent timeout when loading legacy job configuration"
(jenkinsci/ssh-agent-plugin#300), touching only SSHAgentBuildWrapper.java,
ExecRemoteAgent.java, and a new SSHAgentBuildWrapperTimeoutTest.java.
SSHAgentStepWorkflowTest.java is byte-identical between the two tags
(blob 8b2e0c73836b50ec79b58e6c5b12aed18fe608bb).

Reproduced locally against a megawar built from this repo at
417.v1d50b_f28f0e0, run in a container whose PID 1 does not reap:

  [ERROR] Tests run: 45, Failures: 1, Errors: 0, Skipped: 1
  [ERROR]   SSHAgentStepWorkflowTest.teardownDoesNotFailBuildWhenAgentAlreadyStopped:112
  Expected: a string containing "Failed to run ssh-agent -k"
       but: was "... $ ssh-agent -k / Agent pid 1177 killed; / Finished: SUCCESS"

The test asserts the build log contains "Failed to run ssh-agent -k",
which only happens if the teardown's second "ssh-agent -k" fails. Because
ssh-agent daemonizes and is reparented to PID 1, a non-reaping PID 1
leaves the killed agent as a zombie, kill() still succeeds, and the
message is never logged. The build itself succeeds; the assertion depends
on the reaping behavior of the environment.

The same run against 402.vc9cec9230d4b_ passes: Tests run: 30,
Failures: 0, Errors: 0, Skipped: 1.

Extend the Renovate skip range from 403.x-416.x to 403.x-417.x. 418.x and
later are still allowed so a fix is picked up automatically.

See jenkinsci/ssh-agent-plugin#290

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Timeout change breaks existing job configuration and prevents changing these jobs

1 participant