Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need an option to start with clean new Env every build #10

Open
tal5ab opened this issue Nov 21, 2017 · 5 comments
Open

Need an option to start with clean new Env every build #10

tal5ab opened this issue Nov 21, 2017 · 5 comments

Comments

@tal5ab
Copy link

tal5ab commented Nov 21, 2017

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

@cstarner
Copy link

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.

  1. We can hook into the Jenkins Build Process, and cleanup after ourselves automatically.
  2. We can add another DSL Step to call and cleanup the virtualenvs.
  3. We can track all of the virtualenvs we create during a build; if we run into an instance of a virtualenv that already exists, but we didn't create, we recreate it.

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?

@tal5ab
Copy link
Author

tal5ab commented Dec 12, 2017

i would keep it simple , add a flag , and if exist remove the virtualenv if it exist before the script starts

@cjw296
Copy link

cjw296 commented Sep 28, 2018

Would love this too, but what's the Jenkins Pipeline equivalent of the workspace cleanup plugin?

@cstarner
Copy link

cleanWs()

@timblaktu
Copy link

timblaktu commented Mar 11, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants