docker-inbound-agent
docker-inbound-agent copied to clipboard
Bad PATH
Hi, I am trying to declare a pod template image from the inbound agent image. I am simply installing Ruby so that I can use this in my jobs. I would have done this via the OS package manager, but that unfortunately pins the Ruby version in a cumbersome way, that does not allow for newer or older versions to be managed. It's basically the default OS edition of Ruby, or no edition. I would have done this via RVM, but RVM depends on a lot of bash/zsh configurations that do not play well with non-interactive Docker automated contexts, such as found in Jenkinsfiles commands.
I am installing Ruby from source, which uses /usr/local/bin as the default destination for the Ruby executables. As we will see, this too does not play well with non-interactive Docker automated contexts.
The Debian variant of the inbound agent Docker images fail to properly include the /usr/local/bin directory in PATH. When I try to run commands like sh 'bundle install'
in my Jenkinsfile, then the worker container reports that it is unable to find this tool. Performing command -v bundle
in the pod template image reveals that bundle is located in /usr/local/bin
.
There is some silly bash configuration that almost helps. But, of course, most Docker interactions do not actually use bash. That is a flaky dependency. Especially given that Jenkins sh
... steps do not use bash: They default to the POSIX /bin/sh interpreter.
Note that POSIX sh does not traditionally offer many ways to configure non-interactive PATH. Ordinarily, I would use /etc/login.conf and cap_mkdb to correct these gaps, as I often do in Virtual Machines (VMs). However, we are talking about Docker. cap_mkdb is unavailable here. The entire image lineage should ensure that the conventional /usr/local/bin directory is properly added to PATH. Not just for interactive or login bash sessions. But for all shell contexts.
Specifically, adding a Dockerfile directive to an image upstream, would completely solve this problem. The higher upstream this is added, the more images will be able to easily use Ruby and other common Linux software applications.
ENV PATH=/usr/local/bin:$PATH
Update
The problem is more interesting than that. Even with /usr/local/bin added this way, still the sh 'bundle install'
command is failing in the Jenkins worker with the same error. I am curious what is going on there. I this is this simply a result of the root vs jenkins user distinction. I will try to install Ruby as the jenkins user.
I had a similar issue come up today when re-running a test job on my test environment that hadn't ran since before 4.9-1 was released. It ran fine previously but after upgrading to 4.9-1, running sh "unzip file.zip"
now gives me path issues. Reverting back to 4.7-1 resolved my path issues.
Probably want something like https://github.com/jenkinsci/docker-ssh-agent/pull/74