Errors when working in a VM
Opened this issue · 4 comments
Some action's behavior seem to not work well when using VMs. In fact, most actions leverage actions/setup-python and then use the installed environment to perform multiple things. While this work well on Github runners, it's not the case for our self-hosted runners (running in our VMs) as we may already have:
- multiple python version installed which make some step do not go as planned, see https://github.com/ansys-internal/pyaedt-examples/pull/230#issuecomment-2331507013;
- caching directories already existing when running an action;
- ...
A simple work around would be to use virtual environments to ensure that every time an action is called, all of its steps are performed inside of a box that will not impact future CICD execution.
I know @RobPasMue implemented some action or repository that fixes this. Maybe we could think about adding that within the setup-python action.
Yeah this is something different. My problem was with the installation of Python on self-hosted runners (Windows) when using VMs.
What @SMoraisAnsys is showing is something different. In order to properly use Python environments inside VMs it is necessary to activate the virtual environment in every single step. That's what he is working on in #560 I believe. It's a mess... on GH runners this doesn't happen because the runners are ephemeral and you don't care about having a venv. But on self-hosted ones you need to make sure you are cleaning up and using a proper environment. Otherwise you enter into caching issues (cached by the machine itself) and so on.
Yeah that's right. It's even more common that the VMs are shared among multiple projects, each having their own way of setting their environment. On top of adding the environment activation at each step, we also share the same behavior for poetry and pip. I had urgent things to handle so I didn't finished the PR but that should be ok in the coming days. Sry for the delay and thanks both of you for your attention on this issue !
The PR #560 is ready.
@jorgepiloto On top of the previous changes previously mentioned, the PR is also "more compatible" with poetry. In a previous meeting @ludovicsteinbach mentioned that even for packages with poetry as build backend, the default approach of some actions (modified in this PR) was to use pip to install the package. On top of being not aligned with the build backend, this requires one to define two tokens instead of one when one wants to use a private pypi.