artifacts-helper alias does not work in shell scripts

[tudatnms]

Hi, I am using the artifacts-helper to get auth token for .npmrc. It works fine if I run yarn directly from the terminal. However, I see an error when trying to call yarn in a shell script.

error An unexpected error occurred: "Failed to replace env in config: ${ARTIFACTS_ACCESSTOKEN}"

I believe this is because an alias for yarn set in bashrc: alias yarn=/usr/local/bin/run-yarn.sh does not work if I call yarn from a shell script. Currently, as a workaround, I need to have a check if /usr/local/bin/run-yarn.sh exists then run it instead of yarn, something like:

# this is to support codespace (should find a better way to not have codespace specific code in the repo)
if [ -f "/usr/local/bin/run-yarn.sh" ]; then
    /usr/local/bin/run-yarn.sh lint-staged
else
    yarn lint-staged
fi

But I wonder if there is any recommendation to get over this issue to not have this check in all scripts, and also not have codespace specific code in the source repo.

Thanks.

[markphip]

Open to ideas but it is just a hack using bash aliases. Maybe your shell scripts are not using bash? If they are using sh that could be why. Adding the shebang for bash to your scripts would at least not be codespaces specific.

#!/usr/bin/env bash

[tudatnms]

Unfortunately using shebang (e.g. #!/usr/bin/env bash) does not work. I don't think alias will work across either bash/shell scripts, but I'm not sure. Agree that using bash aliases is hacky. I don't have a better idea than calling run-yarn.sh directly in scripts. Will report back if I find a better way. Thanks.

[cmbrose]

#65 might help here - in v2.0.2+ functions are used instead of aliases which should behave better.

Another trick that I found useful when running into a similar issue was to use BASH_ENV to set up default shell imports even for non-interactive shells.

[scaryrawr]

#65 doesn't help here (in all cases). I believe in some scenarios, functions in bash are inherited, but in cases where it is not inherited ~/.bashrc is only sourced for interactive shells.

Trying to source ~/.bashrc from a non-interactive script does not work either because the default code spaces .bashrc contains:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

So having a git hook, or something that'll spin up bash internally will not work as expected when calling yarn or other things that depend on the auth wrapper.

Exploration thoughts

bash

For bash, there is a BASH_ENV variable that can be set to enable sourcing of a script in non-interactive shells:

Invoked non-interactively

When Bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

I think a pain point is that if someone else is using BASH_ENV it's pointing to a specific file, so "ownership" gets weird. (I didn't know about BASH_ENV until we ran into this problem though 😅, so maybe it's not commonly used).

zsh

For zsh, I think we can add the functions to ~/.zshenv instead of ~/.zshrc. ~/.zshenv sounds like it is sourced for all shells interactive or non-interactive, so user's scripts should work as expected 🤞 without knowing the function wrappers are there.

[delilahw]

Hey @scaryrawr, here's an option to use an executable wrapper rather than bash/zsh functions. See (internal repo) clipchamp-codespaces/.devcontainer/features/src/feed-auth-wrapper/template.

Using shell functions to wrap and inject the authentication token didn't suit our repository because:

• it doesn't scale well (some people use other shells, e.g. fish)
• our tooling directly spawns yarn and pip rather than using a shell bash -lc yarn to execute them

To address these requirements, we created a wrapper script that takes precedence over the real yarn/pip/etc on the PATH. The template script (linked above) adds the authentication token to the environment and recursively unwraps itself from the PATH until it hits the real executable. It's worked perfectly for our engineers over the past few months.

[cmbrose]

@scaryrawr sorry I missed this reply!

And yeah, I think you're on the right track. For my team's usage, we have a setup like this:

"ghcr.io/microsoft/codespace-features/artifacts-helper:2.0.2": {
    "targetFiles": "~/.ado-auth-helper.sh"
}

then we add this out our /etc/bash.bashrc:

export BASH_ENV=$HOME/.ado-auth-helper.sh
. $BASH_ENV

For zsh, it sounds like maybe you could just write directly to ~/.zshenv, like this:

"ghcr.io/microsoft/codespace-features/artifacts-helper:2.0.2": {
    "targetFiles": "~/.ado-auth-helper.sh,~/.zshenv"
}

[scaryrawr]

@cmbrose that worked really well for us!

We added the BASH_ENV as part of our devcontainer.json under remoteEnv so that it was picked up for bash scripts even if users used other shells such as zsh or fish:

{
  // ...
  "remoteEnv": {
    "BASH_ENV": "~/.ado-auth-helper.sh"
  }
  // ...
}

[cmbrose]

@scaryrawr nice - remoteEnv was a great idea!