-
Notifications
You must be signed in to change notification settings - Fork 9
Virtual-env name parameter #213
Comments
in general yes. Also this action was built for a typical case where you have one project per job, and one virtual environment. Even when we would allow to define the virtual-env directory, or respect the Right now we add the virtualenv-directory correctly to the Could you explain how you would see From what I see you are probably better off building custom caching, though we can discuss any solution here and I'm happy to review any PR adding functionality here. |
We actually have one project per job. But we're building a bunch of Python projects (each with its own GH workflow) on a shared set of self-hosted GH runners. Without dedicated virtual-envs for every project, the python environment on the runner becomes cluttered with mixed dependencies from these projects which is problematic. My idea was to use your action to neatly create dedicated venvs + caching |
ah, now I understand. I'm happy to review any PR solving this, it would be a nice feature to have. |
I had the same problem with virtualenv being shared between different projects because they might end up being executed on the same self-hosted runner. This seems to work, but I am not happy that I have to explicitly list requirements files, when this action already does an excellent job in tracking them for cache key purposes. @syphar Would you consider deleting the existing environment before restoring cache content? Maybe make it configurable with an input? Alternatively, maybe part of the environment name can be already calculated cache key (at least requirements file hash), so that no deletion is needed, just new env if there is a cache miss? I am open to other suggestions as well and might be able to provide a PR. |
@delicb I could see arguments for both ways.
while this feels more like a things that should be added to the
This is probably the cleaner solution, you could also just add Both ways would be breaking changes, but I lean to just doing a major version bump with a nice release description and wouldn't add more settings for this. |
I am running
n
python projects with potentially conflicting dependencies. Preferably I'd like to use your action to createn
virtual-envs on each runner, linked ton
caches.As I understand it, I can use custom_cache_key_element to create the
n
caches,but they all seem to refer to the same virtualenv:
home/runner/.virtualenvs/.venv/
Is this the expected behaviour?
The text was updated successfully, but these errors were encountered: