[JENKINS-42346] Environment not considered by exec launcher

[jenkins-infra-bot]

See gist.

SSHAgentStepExecution probably needs to be capturing EnvVars from the step context and passing that to the launcher in initRemoteAgent. And ExecRemoteAgentFactory and ExecRemoteAgent would need to pass the EnvVars to every command.

Just never came up before because ssh-agent would not normally care about environment variables other than SSH_AGENT_PID (which should not normally be initially set on the node anyway); $PATH / %Path% is of course relevant when launching the command, but this was only ever tested on Linux, with ssh-agent in /usr/bin.

Probable workaround: preconfigure the %Path% of the computer with ssh-agent available by default (or do that in the agent launcher), rather than relying on withEnv.

---

Originally reported by jglick, imported from: Environment not considered by exec launcher

• status: Open
• priority: Major
• component(s): ssh-agent-plugin
• label(s): environment-variables, windows
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 20260604-211335

Raw content of original issue

See gist.

SSHAgentStepExecution probably needs to be capturing EnvVars from the step context and passing that to the launcher in initRemoteAgent. And ExecRemoteAgentFactory and ExecRemoteAgent would need to pass the EnvVars to every command.

Just never came up before because ssh-agent would not normally care about environment variables other than SSH_AGENT_PID (which should not normally be initially set on the node anyway); $PATH / %Path% is of course relevant when launching the command, but this was only ever tested on Linux, with ssh-agent in /usr/bin.

Probable workaround: preconfigure the %Path% of the computer with ssh-agent available by default (or do that in the agent launcher), rather than relying on withEnv.

[jenkins-infra-bot]

[Original blocks from Jira: JENKINS-36997]

[ogulcanaydogan]

I looked into this. Threading the step EnvVars from the context into ExecRemoteAgent and passing them via .envs(...) on each launch is the obvious fix, but on its own it is not enough: the launcher resolves the ssh-agent / ssh-add command against the agent's own PATH, not the PATH in the passed environment (the usual ProcessBuilder behaviour, where the child environment's PATH does not affect executable lookup). So a PATH set via withEnv does reach the process environment, but it still does not change which ssh-agent binary is picked up, which is the actual problem here.

A proper fix needs to resolve ssh-agent / ssh-add against the pipeline PATH explicitly (locate the executable on that PATH and pass the absolute path to the launch), including the Windows .exe / PATHEXT case. Leaving this open with that note so the .envs()-only approach is not mistaken for a complete fix.

[ogulcanaydogan]

Opened #317 implementing the fix described above: threads the step/build env into ExecRemoteAgent, and resolves ssh-agent against the context's PATH as a fallback when the default lookup fails.

[HannesWell]

Now that we have the executable property since #296, is that even required now?
The only difference I can think of that a special ssh-agent/ssh-add would read additional env variables when being executed?
Or maybe that is already done? Maybe the env variables surrounding a step are already passed into the launched executable?

[ogulcanaydogan]

Good question, let me confirm both parts:

No, the step/build env is not automatically passed into the launched ssh-agent/ssh-add process today. `executeCommand` builds the `ProcStarter` via `launcher.launch()` without any `.envs()` call before #317, so the launched process only sees the agent's own ambient environment, not anything set via `withEnv` in the pipeline. That's the actual gap you diagnosed in the original Jira import.

On the PATH search specifically: you're right that `executable` (#296) already gives users an explicit escape hatch for a non-default ssh-agent location, so that part of #317 is more of a convenience (implicit resolution, like normal PATH lookup) than a strict necessity now. Happy to drop it and keep #317 scoped to just threading the env through if you'd prefer that simpler shape, what's your take?

[HannesWell]

Happy to drop it and keep #317 scoped to just threading the env through if you'd prefer that simpler shape, what's your take?

I'm unsure what the best solution is here. For sure it leads to the greatest flexibility for users if #317 is applied as it is. At the same time there is the functional overlap with the existing executable parameter, as you described. And in order to not bloat the code of the plugin I think it makes sense trying to avoid duplication.

For me the main question is, if relevant use-cases exist where the ssh-agent or ssh-add program would consider any environment variable that could be supplied by a user. Looking at the gist provided for this issue, it seems to me that this issue stemmed from the desire to use the ssh-agent of a git installation on Windows, which this plugin now does automatically.

So maybe the original problem is already solved and no change is needed at all?

[ogulcanaydogan]

That's a fair challenge, and honestly I don't have a strong concrete use case either beyond the PATH problem we already agreed the git-ssh-agent auto-detection solves. ssh-agent/ssh-add are narrow-purpose enough that I can't point to a real scenario where a user-supplied env var (other than PATH) would change their behavior in a way that matters here.

Given that, I think you're right that the original problem is already solved and #317 isn't pulling its weight against the added surface area. Happy to close it rather than keep it open for flexibility's sake alone. Let me know if you'd rather I do that or if you see it differently.