GitHub Actions "neutral" exit code is incorrectly interpreted as failure

Code to Cloud GitHub Actions
#1

GitHub Actions are documented to recognize the exit code 78 as neither passing nor failing:

When an action returns this exit status, GitHub terminates all concurrently running actions and prevents any future actions from starting. The associated check run shows a neutral status, and the overall check suite will have a status of success as long as there were no failed or cancelled actions.

In practice, when a process exits with that code, GitHub reports the Action and containing Workflow as “failed.” The logs end with the following line:

##[error]Docker run failed with exit code 78

Here is a recent example of this.

This was working as expected until my project migrated to the latest beta version of GitHub Actions, so this may be a regression in that release.

25 Likes
#2

I notice that if you remove the yml file and go back to using main.workflow, the UI will say skipped instead of failure. However, you’ll still get a GitHub notification about a canceled build which still seems undesirable.

#3

The neutral exit code isn’t mentioned in the new documentation, so I don’t think it’s supported anymore.

#4

I’m having the same issue.

My use case: I want to run the test suite on the temporary merge commit created for a pull request, similar to how Travis CI runs its pull request builds.

Previously, I had created a custom action that can be run on the pull_request event to check if it was a non-draft non-merged pull request and then check out the temporary merge commit. You would insert this action at the start of your workflow, so it would cancel the remaining steps if the condition was not met (e.g. it’s still a draft) and then continue with the merge commit checked out in the working directory for the next action. It was a bit clumsy, but it worked.

With the new syntax, I realized that I could achieve the same thing using only the built-in checkout action. That action accepts a ref parameter, and I can check the condition with the new if option. However, instead of skipping one step, I want to skip the entire workflow. I thought I could use exit 78 for this (similar to how it worked with the old actions), but then I found this issue… :sweat:

EDIT: I just saw this other issue about the possibility for a job.if option. That would also solve my problem, and would also be more efficient than first spinning up a job just to check the condition. However, I still think there should be a way to cancel a job or workflow while it’s running, either through a special exit code or some kind of built-in function or action.

#5

@mattiasbuelens did you find a solution to this? Just discovered that the “neutral” status is no longer supported, and I would prefer not seeing failed workflows when neutral was intended.

#6

No, I haven’t found a solution yet. I’m hoping that either this issue or the other issue gets resolved, since either would work for my use case.

1 Like
#7

Got word from Github that the “neutral” code 38 was indeed removed and that they’ll employ a different technique in the future. This to avoid ambiguity.

https://twitter.com/ethomson/status/1163899559279497217

7 Likes
#8

I am having the same issue.

I need to be able to skip the entire workflow under certain conditions. Felt like that exit code could be the right thing. 

I could also jam all by logic inside a Javascript action but that sounds counter-productive.

5 Likes