test actions currently fail with a conda error due to multiple miniconda installs

[m-jahn]

The default github action tests started to fail suddenly regardless which repo is used.
Recent example for failure on one of our sm workflows

We always run the formatting, linting, and testing sections on every workflow. The testing runs the workflow a) with the inputs and config defined in the .test dir, and b) same but with the --report option. Now this second report run fails like this, while the first test passes (?!) :

Run snakemake/snakemake-github-action@v2.0.0
Run cat <<EOF > .snakemake.environment.yaml
Run conda-incubator/setup-miniconda@v3
Gathering Inputs...
Creating bootstrap condarc file in /home/runner/.condarc...
Ensuring installer...
Running installer...
  /usr/bin/bash /home/runner/work/_temp/581f6a62-1e14-41b5-8b49-945de356e508.sh -f -b -p /home/runner/miniconda3
  PREFIX=/home/runner/miniconda3
  Unpacking bootstrapper...
  Warning: ln: failed to create symbolic link '/home/runner/miniconda3/_conda': File exists
  
  ln: failed to create symbolic link '/home/runner/miniconda3/_conda': File exists
Error: The process '/usr/bin/bash' failed with exit code 1

Anybody an idea which upstream workflow changed and probably leads to this error message?

[ezherman]

Miniforge was updated 3 days ago. I'm seeing the same error in jobs that combine the snakemake github action with a preceding setup-miniconda step.

Perhaps a (short-term) fix is to ensure jobs have at most one setup-miniconda step? In your case, jobs having at most one snakemake-github-actions step.

[m-jahn]

yes exactly, it seems that suddenly a second attempt to install conda (using the snakemake github action workflow) fails, while before it wasn't a problem. Now, since possibly hundreds of workflows are using the snakemake workflow template and its github action yaml, it would be nearly impossible to fix this downstream. We should rather fix this within the github action directly, by including a test if a miniconda installation in the defaulkt dir already exists, and in that case skip without error.

[ezherman]

What are your thoughts on this approach? Seems to do the trick for my workflows.

ezherman#1

[m-jahn]

Hey Ezra, thanks for looking into this. Yes that would be one option. Another one would be to test if miniconda is already installed which would save some overhead of re-installing to another dir.

[ezherman]

Yep! Although the previously installed miniconda env may have been installed with parameters that the snakemake github actions doesn't expect in its miniconda installation. I wonder whether having a fresh install would be safer.

[m-jahn]

Hi Ezra, I'm currently testing a minimal solution to this problem.
I have thought about several alternatives since I think the github action is a vital part of hundreds if not thousands of workflow tests. Let me briefly explain:

• one option is to add a clean up step that removes the env and the miniconda dir at the end of the action. Advantage: very clean, disadvantage: there might be subsequent steps in user's action workflows that make use of the created env, i.e. by executing conda install X, implicitly assuming that conda is present. These would fail, so this would be detrimental for 3rd party workflows
• another option is the one you suggested: to create a random prefix or suffix and install miniconda in that prefixed dir. The problem I see here is that it creates overhead and possibly confusion between different conda installations. If users use subsequent steps with the snakemake github action in their test run, they usually expect that previous files and 'artifacts' are present and accessible. With your solution, we would end up with two or more consecutive miniconda installs each with random suffixes, which I think creates unnecessary overhead and possibly confusion. What if a user wants to conda install something in a subsequent step? Which installation is then used? Not sure about all the repercussions that could create.
• option 3 is the one I'm testing now, a simple test if conda is already installed in the (now fixed) dir. If yes, it is not installed again

Let me know your thoughts. Maybe my fix is not working after all :-|

[m-jahn]

the fix seemed to work @ezherman maybe you can review or share your thoughts.

[ezherman]

I've reviewed, thank you! Agreed having multiple conda installs could get messy with subsequent steps

[m-jahn]

This issue is temporarily resolved with the pinning of miniforge to 25.9.1 in merged PR #49.
As soon as the issue is fixed upstream in conda-forge, the pin should be removed, but I suggest this is subject to a new more focused issue.