Pass the shell arguments directly to bash

[lazka]

This allows us to run the "run" script using "set -eo pipefail" by default.

The previous wrapper executed the arguments as a bash command string, which
allowed the user to run any command, but didn't give us a chance to special case
if the argument was a script passed from the GHA "run" command.

This is a breaking change.

Porting guide:

• Instead of msys2 mybinary you now have to run msys2 -c 'mybinary'
• To revert the bash error settings you can use set +e and set +o pipefail
  in your run script

See #43

[lazka]

One possibility, I'm open to ideas...

[eine]

Overall, I like the change. Specially, getting rid of OLD_PWD.

However, I'm curious about the behaviour when the default shell is set. FTR, some months ago two different intermediate files were provided: msys2do.cmd and msys2.cmd. The former was the original one, which required to use it explicitly (run: msys2do whatever, and the latter was the one to be used with run: |. Then, I unified both of them.

Now, according to your changes, I would expect the following case to fail:

  job:
    defaults:
      run:
        shell: msys2 {0}
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: 0
    - name: run action
      uses: msys2/setup-msys2@v1
      with:
        update: true
    - run: echo "hello"

That is, the command is echo "hello", so the default shell should be msys2 -c {0}. Nevertheless, that is not the case, because job defaultdirty is precisely that, and it works. So, what's going on?

To make the point more clear, see jobs shell and fshell in https://github.com/msys2/setup-msys2/runs/867268672?check_suite_focus=true

Hence, it seems that the only context where -c is required is for executing msys2 -c "a command" inside a cmd or powershell. In all other cases, the arguments are passed as an intermediate file. It would be useful to make this explicit in the README.

As a result, although this is a breaking change, I would consider it of minor impact (most users should not be using such syntax). We can include it in v1.2.0.

[lazka]

However, I'm curious about the behaviour when the default shell is set. FTR, some months ago two different intermediate files were provided: msys2do.cmd and msys2.cmd. The former was the original one, which required to use it explicitly (run: msys2do whatever, and the latter was the one to be used with run: |. Then, I unified both of them.

We could also add a msys2-bash for setting shell and keep the old command as is, basically replicating the old split and not breaking backwards compat.

Hence, it seems that the only context where -c is required is for executing msys2 -c "a command" inside a cmd or powershell. In all other cases, the arguments are passed as an intermediate file. It would be useful to make this explicit in the README.

When you set the shell the content is always passed through a file according to this https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#custom-shell so, at least for me, everything works as expected. Am I missing something?

[eine]

We could also add a msys2-bash for setting shell and keep the old command as is, basically replicating the old split and not breaking backwards compat.

I'd rather enforce setting the shell and keeping msys -c for very specific cases (or even deprecating it). In the end msys -c is for executing MSYS2 from cmd/powershell, which is not the workflow we want to recommend.

Calling msys arguments from cmd/powershell was the only option when GitHub Actions was moved out of beta, but the service/ecosystem was not ready yet. At that time, it was not possible to set a custom shell (actions/runner#240) so we were forced to bash/cmd/powershell. Ideally, we would set it programmatically (see actions/toolkit#318), so the UX is equivalent to the default bash. Meanwhile, shell: msys2 {0} is the closest we can get.

Hence, I think now is a good moment to introduce this breaking change, before the action is more popular.

When you set the shell the content is always passed through a file according to this https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#custom-shell so, at least for me, everything works as expected. Am I missing something?

No, it is coherent with the current docs. But the environment has been changing and I was slightly outdated.