microsoft / codespace-features

Devcontainer features for use in Codespaces
MIT License
12 stars 8 forks source link

artifacts-helper alias does not work in shell scripts #55

Open tudatnms opened 6 months ago

tudatnms commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 2 months ago

https://github.com/microsoft/codespace-features/pull/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.