Cancel github actions wokflow that uses if:always()

[hcortepi]

Hi there!

I am using github actions as the CI/CD tool to run automated test cases on a given application.

I have been struggling for a while with the if:always() tag, because I want to, at the end of the automation tests run, run a script in a test management platform to update it with the run results.

I want this to be done at all times, meaning that even when the step for the suite run fails, I want this step to happen to check the results. To achieve that I am forced to use the if:always() tag.

There is however some days where the plaftorm I use as test management tool is down or slow. When this happens this step that uses the always tag just keeps on running.

I’ve tried the cancelation thourgh the cancel workflow button or even runnning the command gh run cancel <run_id>, but nothing works.

Is it possible to have a force cancel workflow? If not, given I use a private repo, I will pay for extra minutes when I am not taking advantage of the tool.

Thanks in advance!
Helena

[jsoref]

You might consider setting a timeout on your workflow.

This came up recently, and doesn’t appear to be well documented, so someone should file a bug.

https://docs.github.com/en/actions/learn-github-actions/expressions#always

In short, always() steps aren’t cancelable.

You might be able to use success() || failure() || cancelled() – I’m not sure if cancelled() has the same property.

[ScottSuarez]

Why not just use if if !cancelled() in place of always() ?

Seems condensed logically IMO.

if success() || failure() could also work assuming that false false is returned in case of cancelation.

if success() || failure() || cancelled() doesn't seem correct. This would still run in case of cancelation false || false || true. Thus I believe if !cancelled() to be the most condensed form of expression.

[TWiStErRob]

This is shown in the docs now: https://docs.github.com/en/actions/learn-github-actions/expressions#always

[GMNGeoffrey]

This is really weird behavior. If I cancel a job or a workflow I expect it to, you know, cancel. If I only cancel the jobs that that job depends on, it makes sense that it would run anyway, but if I do something to cancel that job itself, it is super unintuitive that it would not cancel

[brianjmurrell]

I'm using:

    needs: previous-job
    if: ${{ always() && !contains('skip-previous-job', needs.Import-commit-message.outputs.message) }}

to create a workflow that allows a job that a later job may depend on to be skippable, without skipping the depending job. I.e.:

A -> B

so that A runs before B, but A may be skipped and B can still function and should be run. I have not been able to find a way to express that other than the above, which requires the always(), which then makes the job un-cancellable.

[ravwojdyla]

FYI this works best in my case:

needs: previous-job
if: ${{ !cancelled() && (success() || failure() || needs.previous-job.result == 'skipped') }}

[GMNGeoffrey]

Yeah but unfortunately a "skipped" job shows up as a successful status for the purposes of required status checks

[jsoref]

Presumably you could add an extra step that looks to see if certain things are skipped and actively fails itself if it wanted to...

[GMNGeoffrey]

This already is that job, essentially. It's just looking at the status of other jobs and providing an aggregate status (so there's one top-level thing to look at for required checks and such). If I were to create something that checked it, how would I cancel that job? It is desirable to be able to cancel a workflow when GitHub runners are queuing a lot or unreachable (which happens disturbingly frequently).

[maximelebastard]

This always() tag seems to mean too much different things:

• Run it even if the previous task failed
• Run it even if the dependance is cancelled
• Run it even if my deployment is destroying everything and I just want to kill that deployment before its too late

This decision is hard to understand as a user

[TWiStErRob]

I think the infrastructure is doing what we ask it to do...

define:always

I have a feeling that for all your cases there's a reasonable, more explicit alternative. e.g. for "Run it even if the previous task failed" if you don't put an if: always() on the step, then it won't execute if the previous one failed.

[XayOn]

So... once we hit this, how do we finally cancel a job that is already on that situation?
Our minutes are passing, and we can't cancel it!

[jsoref]

Assuming you're writing a workflow, you can add various protections to it, a timeout, perhaps a background task that reads from some other state and kills the main process if it sees your other state ...

[jtcressy]

so if I accidentally get into this scenario where I have an always() job that is stuck, it's stuck forever? I also have a concurrency rule so I'm not able to run any more jobs even after fixing the issue.

Do I need to delete my repo and start over?

completely unacceptable!!!!

[jsoref]

If you don't like the behavior, open a ticket: https://support.github.com/

[PlaceReporter99]

so if I accidentally get into this scenario where I have an always() job that is stuck, it's stuck forever? I also have a concurrency rule so I'm not able to run any more jobs even after fixing the issue.

Do I need to delete my repo and start over?

completely unacceptable!!!!

You might be able to change cancel-in-progress to true to cancel an action that is currently running when another action starts.

[TWiStErRob]

so if I accidentally get into this scenario where I have an always() job that is stuck, it's stuck forever?

@jsoref the default timeout "The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360" doesn't apply here? i.e. does the cancellation not have a hard timeout?

Edit: my bad, the hard deadline seems to be 6 hours, and the wording there is "terminated" which I guess is stronger than "cancelled".

Edit: found one more deadline for cancellation:

After the 5 minutes cancellation timeout period, the server will force terminate all jobs and steps that don't finish running or fail to complete the cancellation process.

[Kolobok12309]

Some workaround for topic, you need use not if: always(), but if: always() && !cancelled().
It successfully cancelled for my test job

custom_condition:
  if: always() && !cancelled()
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello world"
    - run: sleep 30

[GMNGeoffrey]

This workaround is mentioned above. Unfortunately it means that if a previous job was cancelled, this will return a status of "skipped" which counts as passing for required status checks. It doesn't really solve the issue.

[ChristopherHX]

Just a crazy idea, I was also surprised to read skipped jobs are handled like success in branch protections in the docs

I wonder what happens if you make GitHub throw an unhandled exception if and only if a previous job has been cancelled. Then there is only a small timeframe to make your concerns reality. (If you do reruns, I don't know what happens with a previously passing)

custom_condition:
  if: always() && (contains(needs.*.result, 'cancelled') && fromjson('throw') || !cancelled())
  # needs in the job if has access to all transitive dependencies, but you may be surprised of the result field in matrix jobs 
  # always() && can be removed
  runs-on: ubuntu-latest
  needs: test
  steps:
    - run: echo "Hello world"
    - run: sleep 30

fromjson doesn't accept 'throw' as input and will cancel expression evaluation. (If this doesn't happen on initial evaluation you cannot cancel the job)

I even saw some weird skipped conclusions instead of a failure in the past

EDIT Works flawless in my private repo

• pressing rerun deletes the previous passing or failed dependent job
• pressing cancel (before the custom_condition job) will make no job status appear in the commit status list
• pressing cancel during the custom_condition job will cancel the job

No idea if someone can trigger cancellation between job test (success) and job custom_condition (before if evaluation)

EDIT 2

• The mentioned corner case above (e.g. pressing cancel after the previous job set it's result to success) seem to set conclusion to cancelled of the custom_condition job. (see EDIT 3, why it isn't skipped)
• Other call trees of the same workflow continue without beeing affected by the fromjson('throw') code.

This method is probably not officially supported, but it works if you want to abort execution of all dependent jobs without getting skipped in a PR

EDIT 3

This workaround is mentioned above. Unfortunately it means that if a previous job was cancelled, this will return a status of "skipped" which counts as passing for required status checks. It doesn't really solve the issue.

For me the conclusion is cancelled and not skipped, maybe GitHub changed behavior.

[Durinder]

For anyone stuck with an uncancellable run, you can use gh run delete [<run-id>] with the CLI: https://cli.github.com/manual/gh_run_delete

[rking-bennie]

How is no one here getting unknown tag !<!cancelled()> ? My github actions pipeline recognizes cancelled but if i attempt to ! it throws syntax error

[programmer04]

It works as expected @airtower-luna, thanks! But still, it's not a great experience...

Putting something in quotation is rather idiomatic when you want to evaluate it as a verbatim string than an expression. Furthermore, in VSCode it doesn't highlight and check the syntax for if stanza when quoted in opposite to unquoted.

I made PR to documentation github/docs#27497

[ChristopherHX]

BTW (!cancelled()) should also work, because ( is not a reserved in yaml like !.

[brianjmurrell]

What if you explicitly make it a string, like if: '!cancelled()'? Haven't tried it, but logically it should be correct. 🤔

Doesn't putting it in a string make it truthy per the warning:

 Using the ${{ }} expression syntax turns the contents into a string, and strings are truthy. For example, if: true && ${{ false }} will evaluate to true.

[programmer04]

I've tried '!cancelled()' and it works as expected (but it's not so obvious, because you rather expect something to be treated as a verbatim string when quoted in single quotes, not something that executes)

[airtower-luna]

@brianjmurrell, there are different levels here: One is YAML syntax, the other Actions expressions. The issue with !cancelled() (without the quotes) is that it's being interpreted as a YAML tag, and never makes it it the Actions parser. At the YAML level all Actions expressions are simply strings. 🙂

The issue you mention occurs if in the Actions evaluation the value of an if is a string in a way the author of the expression didn't expect.

[brianjmurrell]

I now seem to have an un-cancellable workflow that doesn't use always() in it anywhere.

[brianjmurrell]

Am I misunderstanding something or shouldn't if: cancelled() || success() || failure() be functionally the same as if: always()? It seems they are not. I could not get a job to run with the former until I added always() to it's condition with if: always() || cancelled() || success() || failure().

I even put this if: cancelled() || success() || failure() into a job that proves that at least one of those is true and the job is still only run if I include the always() condition:

  Debug-functional-if:
    name: Debug Functional if
    runs-on: [self-hosted, wolf]
    needs: [Build-RPM, Import-commit-message, Calc-rpm-build-matrix, Import-commit-pragmas,
            Import-commit-pragmas2]
    strategy:
      matrix:
        distro: ${{ fromJSON(needs.Calc-rpm-build-matrix.outputs.matrix) }}
      fail-fast: false
    # NOTE: the always() here is generally bad practice as it makes jobs uncancellable
    #       we only use it here because it's for debugging only
    if: always() || cancelled() || success() || failure()
    steps:
      - name: Is cancelled
        if: cancelled()
        run: echo "cancelled() == true"
      - name: Is success()
        if: success()
        run: echo "success() == true"
      - name: Is failure()
        if: failure()
        run: echo "failure() == true"

which reports:

And only runs at all because I added the always() to the job's if:`. If I remove it, the job is skipped.

[ChristopherHX]

Am I misunderstanding something

Yeah for some legacy reason has success excluded skipped jobs (see azure pipelines docs, they describe it better only different naming)

cancelled() || success() || failure() < = > always() && !skipped()

if: cancelled() can not be cancelled either.

Better use if: (!cancelled()), run always as long not cancelled and get cancelled once pressing cancel

[brianjmurrell]

Closed #26303 as resolved.

Is this really resolved? I think the overall behaviour is quite silly and unintuitive and suspect there are still edge cases that are not achievable.