[BUG] Using bash -l {0} as the default shell causes the pre-installed Julia to take precedence over the setup-julia-installed Julia

[krassowski]

Describe the bug
To my surprise my build started failing due to a compilation issue/packages failing on Julia 1.7. I remember that one week ago I pinned Julia 1.6 version for now, but today I see this is failing again but only on MacOS. It seems that GitHub Actions are switching to a new version of MacOS (11) which maybe (?) includes a preinstalled Julia 1.7: actions/runner-images#4060 ?

To Reproduce
Workflow file to reproduce the behavior:

env:
  JULIA_LANGSERVER: 3.2.0
jobs:
  test:
    name: test
    os: macos-latest
    steps:
      - name: Install Julia
        uses: julia-actions/setup-julia@v1
        with:
          version: '1.6'
      
      - name: Install Julia language server
        run: julia -e 'using Pkg; Pkg.add(Pkg.PackageSpec(;name="LanguageServer", version="${{ env.JULIA_LANGSERVER }}"))'

Expected behavior

Is this expected that the system-wide installation prevails? If yes, I would suggest adding a suggestion to uninstall system-native version on MacOS be added to the readme, otherwise I would just expect the action to take care of it (by making the path to the newly installed julia win out).

Screenshots/Build logs

Clearly system-wide 1.7 wins out:

[SaschaMann]

Is this expected that the system-wide installation prevails? If yes, I would suggest adding a suggestion to uninstall system-native version on MacOS be added to the readme, otherwise I would just expect the action to take care of it (by making the path to the newly installed julia win out).

No, that's a bug. The preinstalled Julia version should not prevail.

Sounds like a PATH issue, I'll take a look.

Thanks for the detailed bug report :)

[krassowski]

Thanks for looking into this. I am less confident about the probable cause now because I cannot find where I read that Julia 1.7 is in included in macOS-11 image...

[krassowski]

Oh, here it says that Julia 1.7 is in MacOS 11 image: https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md

[SaschaMann]

Do you have a link to your workflow run?

I can't reproduce it using the same workflow you posted above: https://github.com/SaschaMann/actions-test/runs/4508514549?check_suite_focus=true

[SylvainCorlay]

I am having the same issue - conflicting julia versions between this action and preinstalled /usr/local/bin/julia.

[krassowski]

My repro was incomplete. I also had:

defaults:
  run:
    shell: bash -l {0}

After adding it I can reproduce it (it fails silently, but you can see that "Updating ~/.julia/environments/v1.7/Project.toml" is there and compilation fails): https://github.com/krassowski/actions-test/runs/4620483928?check_suite_focus=true

[SylvainCorlay]

Note: Julia being installed natively on runners may seem like a win for Julia, but it causes a huge headache to people trying to test several Julia versions/builds. I am having the same kind of issue with conda's julia as well: the system's installation seem to take over.

[SaschaMann]

Note: Julia being installed natively on runners may seem like a win for Julia, but it causes a huge headache to people trying to test several Julia versions/builds. I am having the same kind of issue with conda's julia as well: the system's installation seem to take over.

Go, Python, .NET languages etc. are all preinstalled too. The virtual environment is pretty massive. This issue isn't caused by it being preinstalled otherwise this would be a general problem with GHA that would make it useless for running CI. The issue is caused by the PATH handling of the actions and GHA itself.

[SaschaMann]

Thanks, with that example I can reproduce it.

---

The cause of this problem is the -l parameter of that shell, changing it to bash {0} fixes it. (As a side note, GHA uses bash --noprofile --norc -eo pipefail {0} by default).

The actions toolkit adds things to PATH using a workflow command internally: https://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions#adding-a-system-path

It also sets adds it to path in the step itself by modifying PATH, which is why julia --version in the setup-julia step works correctly.

If we inspect PATH, we can see that the Julia directory ends up somewhere in the middle of it in subsequent steps:

/usr/local/lib/ruby/gems/2.7.0/bin:/usr/local/opt/ruby@2.7/bin:/usr/local/opt/pipx_bin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Users/runner/Library/Android/sdk/ndk-bundle:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/runner/hostedtoolcache/julia/1.6.5/x64/bin:/usr/local/lib/ruby/gems/2.7.0/bin:/usr/local/opt/ruby@2.7/bin:/usr/local/opt/pipx_bin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Users/runner/Library/Android/sdk/ndk-bundle:/Users/runner/.dotnet/tools:/Users/runner/.ghcup/bin:/Users/runner/hostedtoolcache/stack/2.7.3/x64:/Users/runner/.dotnet/tools:/Users/runner/.ghcup/bin:/Users/runner/hostedtoolcache/stack/2.7.3/x64

Based on the content of ~/.bash_profile and ~/.bashrc it seems that GitHub's internal path handling adds directories added via the workflow command before bash -l executes ~/.bashrc, therefore the latter supersedes the manual changes.

---

Is there a specific reason why you need -l?

You can work around this by adding the following step to your workflow:

      - name: Add Julia to ~/.bashrc
        env:
          SETUP_JULIA_PATH: ${{ steps.setup-julia.outputs.julia-bindir }}
        run: |
          echo "export PATH=\"$SETUP_JULIA_PATH:\$PATH\"" >> "$HOME/.bashrc"

and adding an id to the setup-julia step:

      - name: Install Julia
        id: setup-julia
        uses: julia-actions/setup-julia@v1
        with:
          version: '1.6'

(Example run)

Given that setup-julia uses the recommended way to add things to PATH and it works using the standard shells that are available, imo fixing this is out of scope of the action. Messing with ~/.bashrc directly seems more dangerous than it's worth, at least for the action itself.

[SaschaMann]

Given that setup-julia uses the recommended way to add things to PATH and it works using the standard shells that are available, imo fixing this is out of scope of the action. Messing with ~/.bashrc directly seems more dangerous than it's worth, at least for the action itself.

I can look into how other setup-* actions handle this case in a few days but I don't have time for that right now.

[krassowski]

Based on the content of ~/.bash_profile and ~/.bashrc it seems that GitHub's internal path handling adds directories added via the workflow command before bash -l executes ~/.bashrc, therefore the latter supersedes the manual changes.

This seems like a problem with GitHub's internal implementation indeed. Is it something we should raise with GitHub Actions team?

Is there a specific reason why you need -l?

Yes many other actions require it to be added because the software they install relies on the profile files getting loaded.

Thank you for sharing the workaround.

[SaschaMann]

This seems like a problem with GitHub's internal implementation indeed. Is it something we should raise with GitHub Actions team?

I think it's worth a try. It might be the intended behaviour too but it's worth raising it imo.

Yes many other actions require it to be added because the software they install relies on the profile files getting loaded.

I see. I'll check out how other setup actions handle it but I'd also happy to add the workaround behind a flag now that I understand the use case. This might take some time though, so for an urgent fix please try the workaround for now.