Please support something like "allow-failure" for a given job

@vanZeben

As this is a GitHub Actions platform feature request, discussion for this feature has been moved to https://github.com/orgs/community/discussions/15452, please go and put your support behind that community discussion instead of this issue.

We use github actions in our "snapd" project and we love them.

One small feature we would love to see is a way to mark a test job as "allow-failure" (or a term along these lines) [0]. This would simply mean that the overall /pulls overview page would show the PR as with the little green tick-mark (and maybe in the tooltip 5/6 OK, 1 ignored). It would still show as a failure in the details view (maybe with a different icon?).

Our use-case is that we have some CI environments that fail frequently because of external factors like repository mirrors that are our of sync etc. We still want to run the CI on these systems but not get distracted too much by these out-of-our-control issues.

Hope this makes sense.

Thanks!
Michael

[0] E.g.

jobs:
  spread:
    runs-on: ubuntu-latest
    allow-failure: true
    steps:
    - do-some-flaky-stuff

@mvo5

Hey @mvo5 Thanks for the feature request!

We do support marking a step to allow failure via continue-on-error.

We also support marking specific checks as required
That will allow you to merge pr's without a particular job succeeding.

I think the latter should solve your issue at the job level, is there a reason that doesn't well for you?

@thboop

Hey @thboop. Thanks for your quick reply!

Yeah, it's really just about the little green tick at the pull-request overview page. AFAICT when one job (even if it's not required) fails the overview PR list will show this PR as failed. Having a way to mark certain jobs as not rquired would still show the pulls as green (or yellow?) instead of red.

But I do understand this is a bit of a specific request, so feel free to close it if you think it's a bit too odd. We had it with our old CI system and I liked it.

I don't think it is that specific. People have requested this before: https://github.community/t5/GitHub-Actions/continue-on-error-allow-failure-UI-indication/td-p/37033

I just came here via Google as I was surprised I couldn't find anything like this in the documentation. It's standard with e.g. Travis CI

I guess one way to handle this would be for jobs with an allow-failure flag set to generate a neutral conclusion on failure instead of failure. As I understand it, this would let the overall check suite conclusion be success if such a job fails.

I'm also an Actions user who would love to see this feature. My team's project has a long build and a few jobs that are flaky and frequently take a while to fix. We do just ignore failures on those for merging PRs, but being able to make the green tick agree with that convention would be really nice.

This would be great

in the interim, what if there was a step that simply posted the "allowed failures" in a comment (that same comment updated each time the workflow ran). Similar CodeCov.

according to the docs, this is a detectable condition:

https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#steps-context

steps..outcome	string	The result of a completed step before continue-on-error is applied. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, the outcome is failure, but the final conclusion is success.
steps..conclusion	string	The result of a completed step after continue-on-error is applied. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, the outcome is failure, but the final conclusion is success.

I thought that jobs.<job_id>.continue-on-error sounded exactly like this feature, but it doesn't seem to work like that. For me, at least, setting a job to "continue-on-error" still causes a red x for the workflow; it doesn't seem to have any effect at all.

By default, when any job within a workflow fails, all the other jobs are cancelled (unless 'fail-fast' is False).continue-on-error specifies that a certain job failing should not trigger cancelling other jobs. (I would definitely love some way to keep a job from signalling a failing check.)

Not only does continue-on-error not work as expected (as mentioned by everyone on this thread), but the example in the documentation appears to result in a syntax error that I cannot figure out how to get around. As a result, I've been trying all sorts of permutations to figure out if this syntax error is causing continue-on-error not to work as expected.

Maybe it is?

Here's the documentation example verbatim:

runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
  fail-fast: false
  matrix:
    node: [11, 12]
    os: [macos-latest, ubuntu-18.04]
    experimental: [false]
    include:
      - node: 13
        os: ubuntu-18.04
        experimental: true

My version looks similar:

unit-tests:
  name: "Unit Tests"

  runs-on: ${{ matrix.operating-system }}
  continue-on-error: ${{ matrix.experimental }}

  strategy:
    fail-fast: false
    matrix:
      dependencies:
        - "lowest"
        - "highest"
      php-version:
        - "7.4"
        - "8.0"
      operating-system:
        - "ubuntu-latest"
      experimental: [false]
      include:
        - php: "8.0"
          composer-options: "--ignore-platform-reqs"
          experimental: true

When this runs, it fails at the unit-tests job, due to the following error. (See the failure here.)

Error when evaluating 'runs-on' for job 'unit-tests'. (Line: 121, Col: 14): Unexpected value ''

Somehow, it's getting an empty string for runs-on, or at least, that's what this error seems to indicate to me.

When I remove the line that defines experimental: [false] (and only this line), the build runs successfully (see here).

So, maybe the successful build is not actually taking into account the continue-on-error property? Does this syntax error help point to some kind of culprit that could resolve this issue for everyone on this thread?

@ramsey

@ramsey your issue doesn't seem related to the thread. Your job is failing because your include doesn't have a value for operating-system

Why does my include work without operating-system when I remove experimental: [false] from the matrix?

@nschonni

@nschonni You were right. Turns out, I had my matrix messed up. Sorry for the churn here, y'all. 😀

This is one solution

      - name: Install dependencies
        id: composer-run
        continue-on-error: true
        run: composer update --${{ matrix.dependency-version }} --prefer-dist --no-interaction --no-suggest

      - name: Execute tests
        if: steps.composer-run.outcome == 'success' && steps.composer-run.conclusion == 'success'
        run: vendor/bin/phpunit

continue-on-error causes difference in outcome and conclusion!

No updates yet, other than fixing where this got closed :) still tracking this item though so it's something we are aware of. We are still trying to hit our top community items over the next 12 months and this is on that list so watch the space I hope 🤞

docs(ci): document detect-quota limitation and reference allow-failur…

Completely disable Web tests on Windows (rust-random#486)

fail-on-error: false seems to work - see MyIntervals/PHP-CSS-Parser#1551.

That's a feature / option of the coveralls action, not of github actions generally.

              uses: coverallsapp/github-action@v2
              with:
                  fail-on-error: false

@JakeQZ

fail-on-error: false seems to work - see MyIntervals/PHP-CSS-Parser#1551.

@JakeQZ It doesn't work as "allow-failure" did: what we want is that the job itself fails but doesn't impact the overall result; the job does not pretend it succeeds because nobody would look into it even when should (i.e. when a new Python release is near, I want to know if my project works with it or not).

It doesn't work as "allow-failure" did

I thought allow-failure was a proposal in the OP, rather than something that actually ever existed.

@JakeQZ

@JakeQZ it's never existed in GHA - but it already exists in every single other alternative CI provider that has ever existed.

It existed in Travis CI, which provided free CI service for opensource GitHub projects years ago.

The response from GitHub on this and other related issues is just stupid. I'm not going to go into detail about how badly GitHub has missed the mark on this, but the numerous comments and threads just show that they simply don't understand the core problem with the majority of "continue-on-error" use-cases.

And I know why too - so many Actions and GitHub features fail in random ways at random times, and are automatically retried until they succeed, so having them appear red would be confusing. But rather than fix those issues, we're told by their support team to "write your own retry wrappers". I'm getting really sick of the numerous 401 and 403 errors thrown up by GitHub.

Anyway, I suggest they go tinker with GitLab for a bit - a company that knows what it's building and who they are building it for - and they'll quickly see that "continue-on-error" jobs are marked orange, making it very clear that something went wrong but the pipeline continued anyway. Whenever I see an orange job or workflow I know instantly what's going on.

Seeing nothing but green when an error has occurred causes cognitive dissonance and is, frankly, objectively stupid.

Force zero exit on test steps in composite actions

I recently tested whether the Checks API neutral conclusion can be used as a workaround for this. Findings:

What works:

Creating a separate check run via POST /repos/{owner}/{repo}/check-runs with conclusion: neutral works. It renders with a distinct icon (grey, shown as "skipping" in the CLI).
PATCHing a job's own check run mid-execution to conclusion: neutral is accepted by the API.

What doesn't work:

The runner always overwrites the job's conclusion at job completion, so any PATCH to neutral during the job is clobbered by the final success or failure.
Creating a second check run with the same name doesn't collapse with the job's auto-reported check — you end up with two entries.

Conclusion: The server-side already supports neutral as a conclusion. The gap is that the runner unconditionally sets the conclusion at job completion with no way to override it. A conclusion or allow-failure job-level property that tells the runner to report neutral instead of failure would solve this without any server-side changes.

The current workarounds are:

continue-on-error: true — hides failures behind a green checkmark (defeating the purpose)
Let the job fail, mark it non-required — shows a red X which implies something is broken when it's just advisory
Create a separate check run via the API — results in two check entries for one logical check

None of these provide the "warning" semantics that neutral was designed for.

could a workflow_dispatch be set up that runs separately, and overrides the failure to neutral?

could a workflow_dispatch be set up that runs separately, and overrides the failure to neutral?

You'd need to use workflow_run to make it automated and you'd need an app token or PAT (the built-in GITHUB_TOKEN can't modify check runs created by the runner in a different workflow). You'd also have a brief window between the original workflow and the workflow_run where the check would show the original exit behavior of ✅ or ❌. It's technically doable but more complex than it should be.

Navigation Menu

Repository navigation

Please support something like "allow-failure" for a given job #2347

379 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Please support something like "allow-failure" for a given job #2347

Description

Activity

thboop commented on Apr 1, 2020

mvo5 commented on Apr 1, 2020

fingolfin commented on Apr 17, 2020

jhenstridge commented on Apr 28, 2020

jadephilipoom commented on Jul 22, 2020

jakesylvestre commented on Jul 23, 2020

ghostsquad commented on Jul 30, 2020

henryiii commented on Aug 16, 2020

dopplershift commented on Aug 17, 2020

ramsey commented on Sep 10, 2020

nschonni commented on Sep 10, 2020

ramsey commented on Sep 11, 2020

ramsey commented on Sep 17, 2020

szepeviktor commented on Sep 18, 2020

379 remaining items

nebuk89 commented on Dec 8, 2025

JakeQZ commented on Mar 5, 2026

pboling commented on Mar 5, 2026

lilydjwg commented on Mar 6, 2026

JakeQZ commented on Mar 6, 2026

ljharb commented on Mar 6, 2026

lilydjwg commented on Mar 6, 2026

DavidAntliff commented on Mar 19, 2026

atkinsonm commented on May 5, 2026

ljharb commented on May 5, 2026

atkinsonm commented on May 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions