Current usage of action setup-msys2 requires commands to be preprended with msys2do, which is a cmd file (d:\a\_tmp\msys\msys2do.cmd). For example:

  - uses: numworks/setup-msys2@v1
  - run: msys2do makepkg-mingw -sCLfc --noconfirm --noprogressbar

On the one hand, it would be more natural if the shell was selectable as the built-in ones (cmd, powershell, bash), as it would allow a more consistent syntax:

  - uses: numworks/setup-msys2@v1
  - shell: msys2
    run: makepkg-mingw -sCLfc --noconfirm --noprogressbar

On the other hand, such a syntax would hopefully allow to use multi-line run fields, which is not possible ATM (numworks/setup-msys2#8):

  - uses: numworks/setup-msys2@v1
  - shell: msys2
    run: |
      uname -a
      makepkg-mingw -sCLfc --noconfirm --noprogressbar

Apart from that, it'd be useful to have a function in the toolkit core which allows to change the default shell for all the following steps in a job. A possible solution is to allow to set shell at job level (as it is supported for env). However, I think that supporting it in the toolkit would still be useful.

For example, until a month ago, the default shell in windows-latest was cmd. Then, it was changed to powershell: https://github.blog/changelog/2019-10-17-github-actions-default-shell-on-windows-runners-is-changing-to-powershell/. As a result, it is/was necessary to explicitly set shell: cmd in all the steps that won't work with powershell. This is still the case for workflows where certain tests are to be executed on cmd, powershell and/or bash.

Currently, when run: msys2do is used, either with cmd or powershell, msys2do.cmd is found in the path and it is successfully executed. However, it seems that shell: msys2do {0} does not take the PATH set through the toolkit into account,: ##[error]File not found: 'msys2do'

d:\a\_temp\msys\msys2do.cmd {0} is not supported, either: ##[error]Second path fragment must not be a drive or UNC name. (Parameter 'expression')

Using a relative path (..\_temp\msys\msys2do.cmd {0}), shows that the workdir of the parent script is: ##[error]Could not find a part of the path 'C:\hostedtoolcache\windows\Python\3.6.8\_temp\msys'..

Therefore, it seems that a possible solution is to place a dummy file in C:\hostedtoolcache\windows\Python\3.6.8\x64\msys2.cmd, so that a relative path is used. That file will execute d:\a\_temp\msys\msys2do.cmd, which will itself execute bash. Precisely, the following js snippet works:

    fs.writeFileSync('C:/hostedtoolcache/windows/Python/3.6.8/x64/msys2.cmd', [
      `setlocal`,
      `@echo off`,
      `set "args=%*"`,
      `set "args=%args:\\=/%"`,
      cmd + ` %args%`
    ].join('\r\n'));

  - shell: ./msys2.cmd {0}
    run: |
      pacman -Syu --noconfirm
      uname -a

Nonetheless, it feels hackish, specially because of the hardcoded location of msys2.cmd.