Skip to content
This repository has been archived by the owner on Oct 13, 2023. It is now read-only.

Issue with opensuse images losing environment after toolchain invocation #214

Open
xpufx opened this issue Apr 19, 2022 · 2 comments
Open
Labels
bug Something isn't working

Comments

@xpufx
Copy link

xpufx commented Apr 19, 2022

Description

I am trying to add opensuse packaging workflows to a project that already has workflows for a bunch of deb and rpm based distros. At a particular step a shell script needs to be run but it causes an error message as if 'bash' is not installed - but prior steps use the same shell without a problem. Upon further debugging I realized it doesn't matter what the 'run' command/script is. Even if I put something very simple like echo or /usr/bin/env there, I get the same error. The error message in its most basic form is,

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
Error: Process completed with exit code 126.

It says the bash executable is not found but I believe error 126 is a permission error.

Now the reason I am posting this here is because I can use the shell in every step of the workflow before the toolchain step and it works fine. As soon as I run the toolchain step to install cargo/rust and then try to "run" any commands I get a similar error. (Though it doesn't seem to keep an @actions/cache@v3 step from running.)

The issue seems specific to opensuse (leap and tumbleweed). Is there any way I can debug this further?

Workflow code

      - name: "Install Rust"
        uses: actions-rs/toolchain@v1
        with:
          profile: "minimal"
          toolchain: "stable"
          override: true
          components: "rustfmt"
        env:
          ACTIONS_ALLOW_UNSECURE_COMMANDS: "true"
      - name: "Test"
        shell: bash
        run: echo $PATH

Action output

I didn't enable debugging because the toolchain step is not really failing. Below toolchain errors exist verbatim (except container id) on the centos/fedora jobs too. So I doubt the log is very useful.

Run actions-rs/toolchain@v1
  with:
    profile: minimal
    toolchain: stable
    override: true
    components: rustfmt
    default: false
  env:
    ACTIONS_ALLOW_UNSECURE_COMMANDS: true
/usr/bin/docker exec  6057276d172daa3a6091d6775b0488f5c989356a21af00c182726cff89552bd8 sh -c "cat /etc/*release | grep ^ID"
/__w/_temp/f093d162-f057-4f34-b406-54236133158b --default-toolchain none -y
info: downloading installer
error: $HOME differs from euid-obtained home directory: you may be using sudo
error: $HOME directory: /github/home
error: euid-obtained home directory: /root
info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
info: skipping toolchain installation


Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, run:
source $HOME/.cargo/env
/github/home/.cargo/bin/rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /github/home/.rustup

no active toolchain
/github/home/.cargo/bin/rustup -V
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
Installed rustup 1.24.3 support profiles
/github/home/.cargo/bin/rustup -V
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
Installed rustup 1.24.3 support components
/github/home/.cargo/bin/rustup set profile minimal
info: profile set to 'minimal'
/github/home/.cargo/bin/rustup toolchain install stable --component rustfmt
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2022-04-07, rust version 1.60.0 (7737e0b5c 2022-04-04)
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustfmt'

  stable-x86_64-unknown-linux-gnu installed - rustc 1.60.0 (7737e0b5c 2022-04-04)

info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'
info: checking for self-updates
/github/home/.cargo/bin/rustup override set stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: override toolchain for '/__w/wezterm/wezterm' set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.60.0 (7737e0b5c 2022-04-04)

Gathering installed versions
  /github/home/.cargo/bin/rustc -V
  rustc 1.60.0 (7737e0b5c 2022-04-04)
  /github/home/.cargo/bin/cargo -V
  cargo 1.60.0 (d1fd9fe 2022-03-01)
  /github/home/.cargo/bin/rustup -V
  rustup 1.24.3 (ce5817a94 2021-05-31)
  info: This is the version for the rustup toolchain manager, not the rustc compiler.
  info: The currently active `rustc` version is `rustc 1.60.0 (7737e0b5c 2022-04-04)`

Run echo path is ${PATH}
  echo path is ${PATH}
  shell: bash --noprofile --norc -e -o pipefail {0}
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
Error: Process completed with exit code 126.

Expected behavior

Expected current value of PATH to be displayed.

@xpufx xpufx added the bug Something isn't working label Apr 19, 2022
@xpufx
Copy link
Author

xpufx commented Apr 19, 2022

I was able to diagnose this further and get some env info to print by changing shell=bash to shell=/usr/bin/bash {0} and avoid path.

Before the tollchain step PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
After; it becomes PATH=/github/home/.cargo/bin

Intuitevely I know this is not necessarily an issue with this repo since it only happens on opensuse, but can you point me to where I should look? Is it a difference of how the different bash installs behave? A missing profile/rc file - though action runners should not read those I think. Anything?

@wez
Copy link

wez commented Apr 20, 2022

This is where this action manipulates the path:
https://github.com/actions-rs/core/blob/master/src/commands/rustup.ts#L89-L90

that appears to call through to a core module whose docs are over here:

https://github.com/actions/toolkit/blob/main/docs/commands.md#environment-files

That talks about manipulting a file named by the $GITHUB_PATH env var.

https://github.com/actions/toolkit/blob/27f76dfe1afb2b7e5e679cd8e97192d34d8320e6/packages/core/src/core.ts#L109

is the implementation of addPath which looks like it does an azure pipelines add-path command in the case that $GITHUB_PATH isn't set in the environment.

I think this issue might be better off moved to the https://github.com/actions/toolkit repo!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Development

No branches or pull requests

2 participants