Weird behavior chaining multiple commands using &&

[jhasse]

I'm trying to port an AppVeyor script for wxFormBuilder to GitHub Actions. I've noticed that chaining a cd command with another one won't actually change the working directory. Only if I also add ls && at the front: wxFormBuilder/wxFormBuilder@c05b987

I'm not really sure what's going on there, do you have an idea?

[eine]

msys2do does already include bash -c, you don't need to specify it:

setup-msys2/index.js

Lines 37 to 39 in a59619f

	'setlocal',
	'IF NOT DEFINED MSYS2_PATH_TYPE set MSYS2_PATH_TYPE=' + core.getInput('path-type'),
	`%~dp0\\msys64\\usr\\bin\\bash.exe -ilc "cd $OLDPWD && %*"`

So, your commands are expanded to:

%~dp0\\msys64\\usr\\bin\\bash.exe -ilc "cd $OLDPWD && bash -c cd build/3.0/gmake && make config=release"

%~dp0\\msys64\\usr\\bin\\bash.exe -ilc "cd $OLDPWD && bash -c ls && cd build/3.0/gmake && make config=release"

As you see, bash -c cd build/3.0/gmake and bash -c ls are executed in children shells and have no effect on the commands before or after.

[jhasse]

I see. How do I chain those commands using && then?

[eine]

msys2do "cd build/3.0/gmake && make config=release" should work.

[jhasse]

I thought so, too, but make is executed in the wrong directory then: https://github.com/wxFormBuilder/wxFormBuilder/runs/327916925

Maybe some extra quoting is required?

[eine]

I think that there's something else going on there. I just tried:

    - run: msys2do "pwd && cd .github && pwd"
    - run: msys2do "pwd; cd .github; pwd"
    - run: |
        cd .github
        msys2do pwd

• https://github.com/1138-4EB/setup-msys2/runs/327926283#step:5:14
• https://github.com/1138-4EB/setup-msys2/runs/327926283#step:6:14
• https://github.com/1138-4EB/setup-msys2/runs/327926283#step:7:15

So, either the first or the last syntaxes work. The second one does only execute the first pwd, which is expected.

[jhasse]

Could path-type: inherit be to blame?

[eine]

I suggest to replace make config=release with pwd && ls -la, just to be sure that you are where you expect to be and that a Makefile exists.

[eine]

Could path-type: inherit be to blame?

Note that neither path-type nor update are supported in the current v1 tag. Those features were contributed to master recently, and the release has not been updated (see #14 (comment)). I wonder why it did not complain when you used options that are not defined.

[jhasse]

I'm in the base directory as if cd build/3.0/gmake wasn't executed: https://github.com/wxFormBuilder/wxFormBuilder/runs/327939048

[eine]

So, the issue seems to be related to the slashes? https://github.com/1138-4EB/wxFormBuilder/runs/327961332#step:12:11

[jhasse]

Which slashes do you mean? I think that your example works because of the pwd && in the front.

[eine]

Yes, you are correct. It is currently not supported to use &&. Some specific examples do work, but I believe that those are false positives. For your specific use case, I suggest an approach such as the following:

• https://github.com/1138-4EB/wxFormBuilder/blob/master/.github/build.sh
• https://github.com/1138-4EB/wxFormBuilder/blob/master/.github/workflows/windows.yml
• https://github.com/1138-4EB/wxFormBuilder/commit/9f4d132edd22d28aa6c0895a7f48a21e61bc0411/checks?check_suite_id=336612832#step:6:36

[jhasse]

Thank you so much for the support :) I'm using the build script approach now.

[eine]

You are welcome! I hope that actions/toolkit#232 will eventually get some attention from engineers at GitHub, so that we can use #21. Otherwise (if args need to be processed twice, once by a cmd file and then in bash), we are likely to hit multiple issues such as this one.

[lazka]

Not sure if this is the problem here, but try "set CHERE_INVOKING=yes", which makes bash keep the current working directory when executing the passed command.

[eine]

@lazka, I'm afraid it's unrelated. CHERE_INVOKING might replace the cd in https://github.com/numworks/setup-msys2/blob/master/index.js#L37. Nevertheless, the issue with chaining multiple commands is that bash is not called directly, but through a *.cmd file. The proper solution to this issue is actions/runner-images#30.