Closed mahanhz closed 5 years ago
You should be able to utilize the VIRTUAL_ENV environmental variable, when within the withPythonEnv block. It'll point to the absolute path of the base virtualenv folder. It functions similarly to the previous PYENVPIPELINE_VIRTUALENV environmental variable. Granted, it's not relative, but it may work for your purposes
We have currently reverted back to 1.0.4, but I'll try this out when we upgrade again to version 2. In version 1.0.4 I can see that PYENVPIPELINE_VIRTUALENV_RELATIVE_DIRECTORY is defined in the code base, but I do not see VIRTUAL_ENV defined anywhere in version 2.
How is VIRTUAL_ENV defined as the base virtualenv folder?
The VIRTUAL_ENV variable is provided by virtualenv itself. In the new version, I capture changes in the environment with and without virtualenv active. Since that variable is provided (or at least modified) within virtualenv, it will get picked up, and available within the withPythonEnv block
Closing this for now, due to inactivity
@cstarner The recommended workaround does not seem to work for me.
withEnv(["VIRTUAL_ENV=${path}"]) {
withPythonEnv(python) {
body()
}
}
This results in withPythonEnv
still attempting to create .pyenv-python2
within the Jenkins workspace. We previously used PYENVPIPELINE_VIRTUALENV
and pysh
to ensure we got short enough paths to avoid shebang line limitations. This will block us from upgrading to 2.x as well.
In our Jenkinsfile we use the PYENVPIPELINE_VIRTUALENV_RELATIVE_DIRECTORY environment variable.
This is no longer present in version 2.0.0.
Is there an alternative way of accessing the generated python directory?