Inputs take default values on non-manual trigger

[ivansenic]

I have the workflow that is defining the triggers in the following way (full workflow available ➡️ https://github.com/stargate/stargate/blob/master/.github/workflows/release.yml):

on:
  push:
    tags:
      - 'v1.*.*'

  workflow_dispatch:
    inputs:
      publish:
        description: 'Publishing JARs to OSSRH?'
        required: true
        default: false
        type: boolean
      tag:
        description: 'Custom release tag value.'
        required: true
        type: string

and then have a conditional step based on the input like:

      - name: Publish package
        if: ${{ inputs.publish != false }}
        run: ...

I was expecting that when the job is triggered with the tag push, that inputs.publish can not be false and the condition will always resolve to true. I was guided by the documentation about the inputs context, where it's stated:

This context is only available in a reusable workflow or in a workflow triggered by the workflow_dispatch event. You can access this context from any job or step in a workflow. This object contains the properties listed below.

But in the run that was triggered by the tag push, it's clear that the condition resolves as false and step is skipped. How can this be? Are input defaults available in the non-manual triggers?

[airtower-luna]

I have a suspicion at least, and it has to do with type conversion. The push event doesn't have an inputs context, so inputs.publish evaluates to an empty string. And the expression operators documentation describes:

GitHub performs loose equality comparisons.

• If the types do not match, GitHub coerces the type to a number. GitHub casts data types to a number using these conversions: [...]

If you read those rules, false gets converted to zero, and so does an empty string. It's kind of like Javascript. 😅

I'd try this:

        if: ${{ inputs.publish }}

Should work if inputs.publish is a boolean, and an empty string should behave like false.

[ivansenic]

@airtower-luna Thanks so much for point this out to me.. However, I want the step to run if the inputs are not defined.. Can this be done with:

        if: ${{ inputs == null || inputs.publish == true }}

This should work right?

[tatu-at-datastax]

Alternatively it might be easier and more reliable to change logic and name of the input parameter to something like "skipPublish".
While more awkward, it would count on default value for booleans being false. Default for manual trigger could be true.

So check would be something like:

   if:  ${{ !inputs.skipPublish }}

[airtower-luna]

@ivansenic I assume it would, but testing for a missing context isn't something I've tested. Turning the meaning of the boolean around as @tatu-at-datastax suggested is probably the better solution, because it results in a more simple expression. 🙂

[ivansenic]

Yea, I'll follow suggestion from @tatu-at-datastax

[andrea-cassioli-maersk]

I have the same issue, but the proposed solution does not seem to work. Consider the following:

on:
  workflow_dispatch:
    inputs:
      forceDeployment:
        description: 'Force branch deployment'
        required: true
        type: boolean
        default: false
  push:
    branches:
      - main
...

if:  ${{ github.ref_name == 'main' || inputs.forceDeployment }}
  ...

if push is the trigger it seems inputs.forceDeployment is equal to '' and I get an error

Unexpected type of value '', expected type: Boolean.

It seems that the expression fails to evaluate. Any thoughts?

[airtower-luna]

With a push event the whole inputs context is unavailable, which apparently evaluates to an empty string.

You could try:

if:  ${{ github.ref_name == 'main' || inputs.forceDeployment == true}}

The way I understand the equality comparison rules booleans should be compared directly (in that case the == true is redundant), but with different types (string and boolean) both will be converted to integers, with an empty string turning into 0 and true turning into 1.

[IanTaylor-catapult]

This makes sense after being explained. But is absolutely unintuitive and definitely not the way this should function. Why in the world would setting a default for an input variable not be passed into the job regardless of event type? That seems antithetical. So the only way to provide a guaranteed default in input is to add a duplicate variable to the push event, which is illegal as far as I know?

Should this not be clearly stated in documentation? Caused me hours of headaches trying to figure out why expected behavior was failing.

[rlinstorres]

It might be useful for someone!
In our cases, we decided to use a non-native solution by creating a specific job to normalize these inputs, e.g.:

on:
  pull_request:
  workflow_dispatch:
    inputs:
      foo:
        type: boolean
        default: false

jobs:
  normalize_inputs:
    name: Correct Variables
    runs-on: ubuntu-latest
    outputs:
      foo: ${{ steps.normalize_inputs.outputs.foo }}
    steps:
      - id: normalize_inputs
        env:
          foo: ${{ github.event.inputs.foo }}
        run: |
          echo "foo=${foo:-false}" >> $GITHUB_OUTPUT

  another_job:
    needs: [normalize_inputs]
    ...
    with:
      foo: ${{ needs.normalize_inputs.outputs.foo }}