| For others that may be experiencing this issue, here's some information that may be useful. By default, the Jenkins environment on an RPM installed (Linux) system will look like the following:
SHELL=/bin/bash
USER=jenkins
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/
LANG=en_US.UTF-8
HOME=/opt/jenkins
SHLVL=2
LOGNAME=jenkins
_=/etc/alternatives/java
The recommended installation instructions for kubectl on Linux have the binary installed in /usr/local/bin (not in the default path of Jenkins). Even though /usr/local/bin is in the path in bash shells, it's not in the daemon's path with the default settings. Using the PATH+WHATEVER pattern you can get /usr/local/bin in the path for shells, but not the Jenkins process. This allowed me to work around the issue in this way:
withKubeConfig([
credentialsId: '7a1146c7-1791-4197-a8fd-f6a97abec862'
// , contextName: contextName
]) {
// switch context from default to target environment
sh "kubectl config use-context ${contextName}"
// deploy the resources (without pushing)
sh 'kubectl apply -k .'
// wait for deployment to complete
sh "kubectl rollout status deployment/${projectName} --timeout=2m"
}
If I tried to set the context name in the parameter, I got the exception observed in this ticket. This likely stems from the launcher not understanding the PATH+WHATEVER modifications that add /usr/local/bin to the path for pipeline shell commands that you can see above. This feels like a shortcoming of the plugin documentation in that the kubectl binary must be in the path visible to the Jenkins process(es) which can be considerably different from traditional login shell paths or even pipeline shell paths. With the documented installation location as /usr/local/bin, I'm surprised more instances of this haven't occurred. |
