Feature request: always-false expressions due to event name are errors

[webignition]

An incorrect event name reference in an expression can result in the expression always evaluating to false.

An expression that always evaluates to false suggests either:

• the expression is mistakenly incorrect and needs fixing
• a job or step whose execution is controlled by an expression needs to be removed

Take the following simplified workflow as an example:

on:
 push:

jobs:
 build:
   runs-on: ubuntu-latest

   steps:
     - name: Checkout code
       if: ${{ github.event_name == 'pull_request' }}
       uses: actions/checkout@v2

     - name: Build
       run: |
         # Do something with the checked-out code
         git status

The example workflow will always fail. The expression controlling execution of the Checkout code step will always evaluate to false. In this case, either the expression needs changing to github.event_name == 'push' or the expression-controlled step needs to be removed.

Whilst it is probably impossible to determine whether any arbitrary expression always evaluates to false (sounds like a halting problem situation), it is probably possible to determine whether an expression containing an event name reference always evaluates to false as the event names to which a workflow responds are always present.

[rhysd]

Thank you for the suggestion.

Yes, I thought about some kind of constant folding. Since type conversions of expressions of GitHub Actions workflow are quite implicit (for example, 'true' == true is true), it would be hard to apply constant folding in many cases. As you pointed, it would be useful for some specific properties though. I think adding special check to event_name (#69) and then considering about more generic way would be good.

[webignition]

Thanks for the response.

To be perfectly honest, I don't fully understand what you're saying. But that's fine, I don't think I need to!

The example I gave is a simplified version of a recent mistake I made with a workflow and I realised that it could be possible for actionlint to point this error out to me. Whether doing so is easy, practical, feasible or even possible is beyond me.

I'm happy either way whether this type of error can be addressed by actionlint or not, just thought it worth mentioning in case it might be useful.