docker-workflow-plugin
docker-workflow-plugin copied to clipboard
jenkinsci
Potential fix for JENKINS-47415
This just shows one possible fix for this issue I was unable to get the tests to run on my system. It is also quite hard to come up with a valid test case. Help or hints in the right direction would be awesome.
yes would be nice to have a test case for this - not sure I follow how it solves it, if docker is not on the path where the agent is run... that seems odd if you then expect it to be (reading the ticket)
I am having the same problem. Docker executable is in an extra path defined for the Agent as PATH+LOCALBIN with value /usr/local/bin, and the first invocation works, while second fails.
My testcase is simply doing an image build and getting the reference by builtImage = docker.build("corp/project:1.0", ".") and execution fails right after building (I've added the stack trace to the issue).
@michaelneale it is one the PATH defined in the Agent setup environment. But this is not used for the version check call. It looks in the default PATH in my case macOS which doesn't include /usr/bin/local by default
@Larusso how is the default PATH defined on macos? I always assumed it was ~/.profile for running user.
@michaelneale No. macOS doesn't run a ~/.profile or ~/.rc file during system start.
It uses ~/.bash_profile etc for the users yes. But I don't want to keep special Agent setups in the user directory. That is why Jenkins allows me to setup the PATH in the Node configuration :). I can get the docker stuff to work on my master machine when I start jenkins with a user context or launchd. But not the nodes. I would need to configure each machine with a custom profile script which I don't want. I am also not allowed to set symlinks in usr/bin whatever because of this secure root feature in macOS.
And as you can see in my patch, the solution is easy. The test setup is not.
I had to actually edit the docker-commons-plugin to return /usr/local/bin/docker as the executable, since it seems the process runner used here is not resolving the path from the environment, even if the environment contains the correct paths.
Are there any news on this on what one can do on OSX slaves? Using /etc/paths or ~/.bash_profile does not work.
Would really like to see a test for this as well, but not sure yet how to do so...
Couldn't we simply test that the envVar for the Dockerclient, matches the envvar of the node?
