Open tal5ab opened 6 years ago
This would be a nice feature. At the very least, I think that we would need a setting that determines whether or not the workspace is cleaned up after the build; one that defaults to True.
As I see it, we can go about the actual cleanup in a couple of ways.
2 I think can be ruled out right away; this project has already had to create more than enough steps and I am reluctant to add more. 1 would be the cleanest, but the approach of 3 would ensure idempotency, which is more in line with good CI practices.
Do you have a preference either way? Or do you see a different approach to this problem other than the ones I outlined?
i would keep it simple , add a flag , and if exist remove the virtualenv if it exist before the script starts
Would love this too, but what's the Jenkins Pipeline equivalent of the workspace cleanup plugin?
cleanWs()
I found this plugin thinking its main utility was to clean up pipelines using pyenv
and pyenv-virtualenv
, replacing instances of sh pyenv virtualenv <python_version> <venv_name>
and sh pyenv activate <venv_name>
with a single withPythonEnv(venv_name) {}
.
Scanning issues I found this one which seems pretty critical for adoption. It's been a while, but I wanted to check.. are you (@cstarner, @cjw296, @tal5ab) all still using this plugin for managing venvs on Jenkins projects, and if so, what are you currently doing to force a clean slate and recreate the venv when you need to?
My initial tests with this plugin have taught me that it does not actually behave as I described above. The docs make it clear that the string arg to withPythonEnv
must be a python executable or a pre-existing venv name.
When I correct this and pass it the path to a python interpreter installed by pyenv, e.g. PYTHON_INTERPRETER_PATH
:
PYTHON_VERSION = "3.9.0"
PYTHON_INTERPRETER_PATH = "/home/jenkins/.pyenv/versions/${PYTHON_VERSION}/bin/python"
I see from this plugin's output that it is using python -m venv
to generate the venv, not pyenv-virtualenv
, and it sticks the venv at the root of the workspace:
10:17:51 [Pipeline] withPythonEnv
10:16:08 $ /home/jenkins/.pyenv/versions/3.9.0/bin/python --version
10:16:08 $ /home/jenkins/.pyenv/versions/3.9.0/bin/python -m venv /home/jenkins/.jenkins/workspace/eering-services-vsphere-template/.pyenv-home-jenkins-.pyenv-versions-3.9.0-bin-python
None of this is very useful for me, as I really just wanted to replace this pattern:
steps{
sh """#!/bin/bash -l
pyenv virtualenv ${PYTHON_VERSION} ${PYTHON_VENV_NAME} || true
pyenv activate ${PYTHON_VENV_NAME}
pip3 blah blah
python blah blah
"""
}
with something like:
withPythonEnv("${PYTHON_VERSION}", "${PYTHON_VENV_NAME}") {
sh """#!/bin/bash -l
pip3 blah blah
python blah blah
"""
}
I appreciate that this plugin must be useful to others, or it wouldn't exist, so I'm just curious if those still actively using this could identify their use case, and/or provide some feedback on how/whether I can achieve my simple desire with this plugin. Perhaps I should just functionalize pyenv_create_and_activate
in a shared library instead of using this plugin?
Right now i am forced to uninstall or use --upgrade --force-reinstall to get my latest build installed for testings Will be nice to have an option that starts a new env every build