Use the Github action on a self-hosted runner

[HealthyPear]

Discussed in https://github.com/showyourwork/showyourwork/discussions/472

^{Originally posted by **HealthyPear** September 9, 2024} As my workflows take quite a while and I am forced to use private repositories, I need to run them on a self-hosted machine. Unfortunately the machine I can use is not self-administered, and the pip installation is externally managed, leading to this error when _showyourwork_ gets installed, ``` WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip. Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue. To avoid this problem you can invoke Python with '-m pip' instead of running pip directly. error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try zypper install python311-xyz, where xyz is the package you are trying to install. If you wish to install a non-rpm packaged Python package, create a virtual environment using python3.11 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. If you wish to install a non-rpm packaged Python application, it may be easiest to use `pipx install xyz`, which will manage a virtual environment for you. Install pipx via `zypper install python311-pipx` . note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. ``` Did anyone ever manage to use showyourwork's GitHub action in pair with an action which provides its own pip installation? I tried with both [setup-python](https://github.com/marketplace/actions/setup-python) and [setup-micromamba](https://github.com/marketplace/actions/setup-micromamba), but _showyourwork_ always tries to use the default pip installation. Maybe this is a limitation of the action? Technically this action should download and install its own `miniconda` installation, https://github.com/showyourwork/showyourwork-action/blob/202dc7105b319bea583f0e406d42a0f8a6c0fa5a/src/conda.js#L55 so I do not understand if it's a mistake on my side.

UPDATE

OK I found what is the problem and I think it's something that needs to be changed on the GitHub action side.

The part where showyourwork is installed by the action is performed in src/conda.js,

async function setupConda() {

  if (CACHE_CONDA) {
    // Restore conda cache
    core.startGroup("Restore conda cache");
    const conda_cacheKey = await cache.restoreCache(
      conda_paths,
      conda_key,
      conda_restoreKeys
    );
    core.endGroup();
  }

  // Download and setup conda
  if (!shell.test("-d", "~/.conda")) {
    exec(
      "wget --no-verbose https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ./conda.sh", 
      "Download conda"
    );
    exec("bash ./conda.sh -b -p ~/.conda && rm -f ./conda.sh", "Install conda");
    core.startGroup("Configure conda");
    exec("conda config --add pkgs_dirs ~/conda_pkgs_dir");
    exec("conda install -y pip");
    core.endGroup();
  }

  // Install showyourwork
  exec(`pip install -U ${SHOWYOUWORK_SPEC}`, "Install showyourwork");

where const conda_paths = ["~/.conda", "~/.condarc", "~/conda_pkgs_dir"];.

The problem is that if you are running on a self-hosted runner as in this case the conda installation might be already present (i.e. the .conda folder exists and there is something inside. Though, this something might not be the conda installation but just some user-related info about the existing environments (see https://github.com/conda/conda/issues/5388). In my case it contains only an environments.txt files with the path of all existing environments, but my conda installation is somewhere else.

There is nothing in the GitHub Action that deals with an existing conda installation at some path.

Given this I think this should be a proper issue.

[HealthyPear]

I think a good solution should be to add a new option to the action where one inputs the path of the existing conda installation and an environment for the runner, like

conda-installation-path:
    description: "Path to an existing installation of conda when calling this action"
    required: false
    default: "~/"
conda-env-runner:
    description: "Name of the conda environment to use on the runner"
    required: false
    default: "showyourwork-runner" # maybe this could be suffixed with the RUNNER_NAME, GITHUB_REPOSITORY and GITHUB_REF_NAME

then, if defined, we use that to activate the base environment, create the environment (which should be cached optionally cached I guess?) and continue.