How to share shell profile between steps? (or: how to use nvm/rvm in steps?) #25061
-
I have a workflow consisting of two jobs: frontend (nodejs) & backend (ruby); that I’m attempting to migrate from TravisCI. The frontend code uses NVM with an The backend code uses RVM with a TravisCI build environments come with both NVM and RVM pre-installed. The version of Ruby specified in In Github Actions virtual environments, default versions of both Ruby & Node.JS are pre-installed, however version managers such as NVM/RVM are not. The ‘official’ way to install a different Ruby/Node version in Github Actions appears to via actions/setup-ruby and actions/setup-node. Unfortunately, To emulate TravisCI, I’m trying to install both NVM and RVM as the first steps in their respective jobs, so that the jobs can use the .nvmrc and .ruby-version files to detect & install the appropriate runtime versions. The challenge I have is that both NVM and RVM expect to be sourced into the shell after installation, e.g.
As I’ve discovered, each
(explicitly instructed to not read from I tried adding an explicit Below is an example workflow. For nvm: the For rvm: the
For the frontend job, I had expected It seems that the changes to Is there a way that I can have the NVM/RVM scripts sourced into all subsequent shell processes in a job? (also, having to repeat |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
You were close: You can actually just add I am aso assuming that install script primarily exports/updates the PATH to include the nvm install location, so youd only need to add the shell option for steps that need to exec node The default was to invoke bash non-interactive and non-login since semantically thats closest to what we are doing- just running scripts, and I wanted to avoid adding potential side effects, unexpected behavior, re-running the same statup files repeatedly for each step, etc. The shell option was intended to allow you to manage these types of scenarios as necessary. Its not really the expected default behavior since we have setup actions that download/install tools and modify the PATH, etc, so that the tools installed are available everywhere not just from bash steps that pass down the environment, PATH is tracked by the runner across steps, etc |
Beta Was this translation helpful? Give feedback.
-
To have a working sample snippet. Adding a local Composer’s bin to the path. The Drupal step would fail without shell: bash -l {0}.
|
Beta Was this translation helpful? Give feedback.
-
Putting this here as it's an issue I ran into. If you don't also set -e the job status may not update correctly (this may only happen if the script is run in a composite action though). i.e. |
Beta Was this translation helpful? Give feedback.
You were close: You can actually just add
shell: bash -l {0}
(the -l was missing from yours) for steps where you need to source the bash_profile. See: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html,I am aso assuming that install script primarily exports/updates the PATH to include the nvm install location, so youd only need to add the shell option for steps that need to exec node
The default was to invoke bash non-interactive and non-login since semantically thats closest to what we are doing- just running scripts, and I wanted to avoid adding potential side effects, unexpected behavior, re-running the same statup files repeatedly for each step, etc. The shel…