Github Actions if condition requires "always()" to run but that makes it not cancellable

[mauriciodou]

Hi Community.

I am having this weird situation where my job’s if condition requires to have the “always()” function in order to run. If I use another function like “success()” or even putting “true” hardcoded doesn’t work. The problem with using “always()” is that now the job cannot be cancelled.

Here’s the job if piece:

  WorkspaceVariables:
    needs: [build-matrix]
    env:
      terraservice_name: "00-workspace-variables"
    if: |
      always() &&
      needs.build-matrix.result == 'success' &&
      needs.build-matrix.outputs.matrix != null &&
      contains(fromJson(needs.build-matrix.outputs.all-matrix).terraservice, 'environments/dev-centralus/00-workspace-variables') &&
      contains(fromJson(needs.build-matrix.outputs.matrix).terraservice, 'environments/dev-centralus/00-workspace-variables')

[Katsute]

use success() || failure() , it should make the job always run but also not run if you cancel.

[mauriciodou]

Tried that but behaves like the case I said of removing the always() the job is skipped 😦

[ChristopherHX]

@mauriciodou

You want, success is false if any job where skipped

if: "!cancelled()"

My own cheatsheet for job if’s

  <a href="https://github.com/actions/runner/issues/491#issuecomment-926924523" target="_blank" rel="noopener nofollow ugc">github.com/actions/runner</a>

Job-level "if" condition not evaluated correctly if job in "needs" property is skipped

<div class="github-info">
  <div class="date">
    opened <span class="discourse-local-date" data-format="ll" data-date="2020-05-19" data-time="22:07:13" data-timezone="UTC">10:07PM - 19 May 20 UTC</span>
  </div>


  <div class="user">
    <a href="https://github.com/joequincy" target="_blank" rel="noopener nofollow ugc">
      <img alt="joequincy" src="https://user-images.githubusercontent.com/44845461/181093282-7ebfb799-4d37-4f67-9570-d0ec1d94025d.jpeg" class="onebox-avatar-inline" width="20" height="20">
      joequincy
    </a>
  </div>
</div>

<div class="labels">
    <span style="display:inline-block;margin-top:2px;background-color: #B8B8B8;padding: 2px;border-radius: 4px;color: #fff;margin-left: 3px;">
      Service Bug
    </span>
</div>

**Describe the bug** If a job `needs` a prior job which has been skipped, the `…if` condition for the dependent job may behave unexpectedly under some conditions. (unsure if condition is evaluated incorrectly or if it's not evaluated at all)

To Reproduce
Steps to reproduce the behavior:
Given a workflow such as this (where job_b needs to complete or be skipped before subsequent jobs run, but subsequent jobs don't depend upon any outputs from job_b)

on: push

jobs:
  job_a:
    runs-on: ubuntu-latest
    outputs:
      truthy_string: ${{ steps.a.outputs.always }}
      null_value: ${{ steps.b.outputs.never }}
    steps:
      - id: a
        run: echo "::set-output name=always::something"
      - id: b
        run: echo "We opt not to set any output at this time"
  job_b:
    runs-on: ubuntu-latest
    needs: job_a
    if: needs.job_a.outputs.null_value
    steps:
      - run: echo "We've ensured this job will be skipped"
  job_c:
    runs-on: ubuntu-latest
    needs: [job_a, job_b]
    if: needs.job_a.outputs.truthy_string
    steps:
      - run: echo "This won't run, even though the IF condition evaluates true."
  job_d:
    runs-on: ubuntu-latest
    needs: [job_a, job_b]
    if: always() && needs.job_a.outputs.truthy_string
    steps:
      - run: echo "This will run, even though we've only changed the condition from `true` to `true && true`"

Examining the output of this workflow, job_a will always run, job_b will always be skipped, job_c will always be skipped, and job_d will run.
The only difference between job_c and job_d is the addition of always() && to the if condition.

Expected behavior
If a job-level conditional evaluates to true, the job should run after all needs'd jobs have completed or been skipped.
Both job_c and job_d should run. The always() && should not be required for job_c, since it doesn't change the ultimate true/false result of the conditional.

OR documentation should be updated to indicate this is expected behavior. The current docks simply says of job needs (emphasis added):
> Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue.
This is relatively ambiguous, but the plain interpretation is that a conditional statement that evaluates to true should cause the job to continue. As seen with job_c in the sample, that isn't always the case.

Runner Version and Platform

Version of your runner?
Unsure - I'm only running via Github Actions, not using a self-hosted runner.

OS of the machine running the runner? OSX/Windows/Linux/...
Linux: ubuntu-latest

What's not working?

Jobs are being skipped even when the job-level conditional evaluates to true.

Job Log Output

Because the job is skipped entirely, there is no job-level output, even if the appropriate DEBUG secret is set.

Runner and Worker's Diagnostic Logs

As above, there is no additional output, even if the appropriate DEBUG secret is set.

[mauriciodou]

That worked like a charm @ChristopherHX thanks a lot for the cheatsheet

[sagartrivedi11]

facing similar issue even without using needs. I have only one job which is doing nothing but just waiting still unable to cancel the run.

jobs:
  initial-job:
   runs-on: [runner01]
   if: always()  
   steps:
   
    - uses: actions/checkout@v3
    - name: Wait 
      run: sleep 3600

@ChristopherHX any suggestion ?