Avoid warning: SUDO_USER: unbound variable

[ssbarnea]

It would be nice to avoid displaying warnings when our scripts start:

bash: SUDO_USER: unbound variable

I am still trying to figure out from where it comes but for sure it is happening only on jobs using this action and appears on action itself and also on all following run: steps, so I suppose it has something to do with the wrapper.

[Vampire]

I'm moved this to a discussion, as it is more a usage question than a bug or feature.
The default wsl-shell-command value contains the u flag which errors out if you use an undeclared variable.
Those usages are most often a typo like trying to read SUDO_USRE instead of SUDO_USER.
You can either use variable-substitutions that use default values if the variable is not set, for example for variables set outside the script and just read within, or you can disable this behavior by configuring a custom wsl-shell-command without the u flag.

[Vampire]

My first guess would be because you are trying to run an interactive shell in a non-interactive context and that because of that some login scripts are run that reference that missing variable or something like that.
You use bash -i -euo pipefail as wsl-shell-command where the default is bash --noprofile --norc -euo pipefail.

Or maybe it is because you use sudo in your command sudo apt-get update && sudo apt-get install -y curl and that uses this variable that is not set.

Actually using sudo should be unnecessary in your case anyway, as the default user of the distribution should be root and you are not using wsl-shell-user to select a different user, so root will execute the command anyway.

Besides that, you could actually even omit the whole first line of the run step and just not set update to false and configure curl in additional-packages, then the action does both for you, but I guess you are aware of that.

[Vampire]

Yep, I tried it now, my first assumption was right.
sudo is not relevant, even if I just run id with the interactive shell and -u configured like you have it, it shows the warning.
Well, it's just a warning and does not make your build fail, so you could probably also choose to ignore it.

[ssbarnea]

Probably we could add env: SUDO_USER=root to silence it. Tx

[Vampire]

Btw. I now let a test run with run: find / -type f -exec grep SUDO_USER {} + and it shows that the file in question is /etc/bash.bashrc with content

# System-wide .bashrc file for interactive bash(1) shells.

# To enable the settings / commands in this file for login shells as well,
# this file has to be sourced in /etc/profile.

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, overwrite the one in /etc/profile)
# but only if not SUDOing and have SUDO_PS1 set; then assume smart user.
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi

# Commented out, don't overwrite xterm -T "title" -n "icontitle" by default.
# If this is an xterm set the title to user@host:dir
#case "$TERM" in
#xterm*|rxvt*)
#    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
#    ;;
#*)
#    ;;
#esac

# enable bash completion in interactive shells
#if ! shopt -oq posix; then
#  if [ -f /usr/share/bash-completion/bash_completion ]; then
#    . /usr/share/bash-completion/bash_completion
#  elif [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#  fi
#fi

# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found/command-not-found ]; then
   function command_not_found_handle {
           # check because c-n-f could've been removed in the meantime
                if [ -x /usr/lib/command-not-found ]; then
              /usr/lib/command-not-found -- "$1"
                   return $?
                elif [ -x /usr/share/command-not-found/command-not-found ]; then
              /usr/share/command-not-found/command-not-found -- "$1"
                   return $?
           else
              printf "%s: command not found\n" "$1" >&2
              return 127
           fi
   }
fi

And yes, I guess you can "fix" the warning by setting the env var.

[ssbarnea]

Super! My hope was that we will endup making a pull request to Ubuntu/Debian to get it fixed.