Adds socketPath configuration to allow setting a predictable path
#62
Conversation
This change is relevant for situations where we need a predictable path for this file. For example: - If we do builds in kubernetes builders and we want to share the socket across multiple containers in the builder pod, having this predictable path helps configuring the volume mount for it. Otherwise we need to mount the whole /tmp which is not always the best option.
|
@jglick Any chance we could get this merged? With the removal of the built-in java ssh-agent provider, and it now relying directly on ssh-agent cli being available, for jobs spawning in Kubernetes, this means we now need ssh client tools installed in any container in which we want to load the ssh-agent via pipeline syntax. We don't want to go the route of having to mount a shared /tmp across the pod, for obvious reasons. By being able to override the socket path, we can instead still create a shared volume (mounting to something other than /tmp), load the ssh-agent from within the JNLP container, and have ssh-agent access across all containers within the pod, without having to install ssh client tools in other containers, some of which are third party maintained |
Possibly better for the plugin to use At any rate, I am not considering myself a maintainer of this plugin. Should probably be marked as up for adoption by someone who can actually commit to not just merging PRs but thinking carefully about impacts, and tracking regressions. As of the switch to the exec provider by default, it does not really add anything essential; more transparent and flexible to run |
|
Addresses a corner case which can be handled by simply not using this plugin. |
This change is relevant for situations where we need a predictable path for this file.
For example:
If we do builds in kubernetes builders and we want to share the socket across multiple containers in the builder pod, having this predictable path helps configuring the volume mount for it. Otherwise we need to mount the whole /tmp which is not always the best option.
Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
Ensure that the pull request title represents the desired changelog entry
Please describe what you did
Link to relevant issues in GitHub or Jira
Link to relevant pull requests, esp. upstream and downstream changes
Ensure you have provided tests - that demonstrates feature works or fixes the issue