Describe the bug

Comparing a boolean input in a workflow_call must be done against a boolean value and always yields false otherwise.

Comparing a boolean input in a workflow_dispatch must be done against a string value and always yields false otherwise.

To Reproduce

GIVEN a workflow_call with:

 on:
  workflow_dispatch:
      dry_run:
        required: false
        default: true
  workflow_call:
      dry_run:
        required: false
        default: true

WHEN evaluating the input dry_run yields:

 # for the workflow_call event
 echo "dry_run=${{ inputs.dry_run == 'false'}}" # -> false
 echo "dry_run=${{ inputs.dry_run == 'true'}}" # -> false
 echo "dry_run=${{ inputs.dry_run == true }}" # -> true
 
 # for the workflow_dispatch event
 echo "dry_run=${{ inputs.dry_run == 'false'}}" # -> false
 echo "dry_run=${{ inputs.dry_run == 'true'}}" # -> true
 echo "dry_run=${{ inputs.dry_run == true }}" # -> false

PS:

• the example is from a step..run but this at least happens also in a job.<id>.if):

• for extra confusion serves this (correct behaving) bash comparison which works for both events:

  if [[ "${{ inputs.dry_run }}" == "true" ]] ;

Expected behavior

In dependent of the event, the behavior should be the same.

Thoughts on fixing/mitigating this fast(ish)

I guess aligning this is going to breaking existing workflows.

Hence, in the meantime:

1. this totally unexpected behavior must be guarded with a syntax error/warning during workflow execution, when attempting a comparison of incompatible types yielding always false as a result.
2. the inconsistent behavior should be documented on the respective event's documentation.

Runner Version and Platform

Current runner version: '2.320.0'

Ubuntu
22.04.5
LTS