Reusable workflows do not respect conditional steps based on inputs.

Describe the bug Reusable workflow does not respect conditional inputs. The current behavior is that they run all steps listed in the reusable workflow. This is related to #1602.

To Reproduce Steps to reproduce the behavior:

1. Create a reusable workflow that uses inputs in its conditional steps.
2. Run
3. See error

Expected behavior That I can conditionally run steps in a reusable workflow.

Runner Version and Platform

Version of your runner? 2.304.0

OS of the machine running the runner? OSX/Windows/Linux/… macOS arm64

What’s not working?

My conditionals attached to steps in a reusable workflow should be respected. They are not and both steps will trigger.

Job Log Output

If applicable, include the relevant part of the job / step log output here. All sensitive information should already be masked out, but please double-check before pasting here.

Runner and Worker’s Diagnostic Logs

If applicable, add relevant diagnostic log information. Logs are located in the runner’s _diag folder. The runner logs are prefixed with Runner_ and the worker logs are prefixed with Worker_. Each job run correlates to a worker log. All sensitive information should already be masked out, but please double-check before pasting here.

Runner_20230612-205711-utc.log Worker_20230613-180512-utc.log

[ChristopherHX]

if: ${{inputs.platform}} == 'android'

Not even the vscode actions linter complain about this not implemented syntax.

It is effectively the same as writing true, because the result of the if is a non empty string and not a boolean.

The runner and the Actions Service only supports something like

if: inputs.platform == 'android'

I would really expect an error message on the runner and service telling the workflow author there is a syntax error in the if expression

[jason-edstrom]

I changed the conditionals to one of the formats I mentioned: if: ${{inputs.platform}} == android. I also removed the /dev/null. to bring back the failure state. It does look like the /dev/null was eating some logging.

mkdir: ./actions-runner-osx-arm64-2.304.0/_work/retail-mobile-apps-sandbox/retail-mobile-apps-sandbox/apps/rn-apps/mercury/codepush: File exists
Error: Process completed with exit code 1.

I ran this to see if mkdir with the directory existing causes a failure state:

mkdir ./apps/rn-apps/mercury/codepush; mkdir ./apps/rn-apps/mercury/codepush-2/

It doesn’t seem to block the successful execution of the second mkdir command. Does that seem accurate?