Thanks @weide-zhou that looks like it will solve the issue. I’ll give it a shot.

But, how do I put an if condition on a job based on the step output of a previous job in the workflow?

Having a similar issue here.

Our use case is this:

We have a parent repository, and whenever there’s a push on the parent repo, we have a set of child repos, which should be built incrementally.

This incremental build is handled by a workflow. But when we have multiple commits (within a short time period) on the parent repo, there will be many incremental build workflow runs are triggered. Therefore, we wanted to cancel any already running workflow runs before running a new one. But this marks the cancelled workflow as a failed one, which isn’t the case here. Is there a workaround for this?

Hi! Is there a way to avoid to put if in all the jobs? Too much code duplicated...

@weide-zhou I would agree with @cgr71ii ... this introduces a lot of code duplication and if you miss in a step refinement of the GHA workflow the if condition you end up with a half broken execution.

If there is a gh CLI/REST cancellation functionality, why is there not one for gracefully stopping a GHA workflow?

It is possible to cancel via the GH API, but you create a "cancel request", which means you need to hold/wait the action (sometimes up to 30s or more) to prevent further steps from progressing, while polling the API to see if it has canceled. There's a couple OSS actions which implement this behavior, but it's sub-optimal at best.

Unfortunately there is no "reserved" exit code for processes to indicate signals (e.g. exit 127 for "Cancel" instead of "Error"), and there's no reserved namespace in $GITHUB_OUTPUT that could be used, and the Job process itself doesn't have permissions to signal the parent Runner process directly.

Someone would have to implement a $GITHUB_CANCEL or similar semaphore file which could be written to by the Step process and picked up at the end of the Step by the Runner to indicate it should Cancel the workflow via the API (same behavior as the OSS Actions), or do an in-flight modification of the remaining Job metadata to effectively add if: false to skip the rest of the Workflow.

Anyway.

We have CI with concurrency group configured. It cancels all CI on a branch if a new commit pushed.
All these cancelled workflows are reported as failed in email reports. There is no way to bypass that with if statement.
I'll be happy to have a way to cancel without marking as failed.