Job stopping on new push?

So I have a workflow that triggers on [push,pull-request]
in essence nothing fancy. Just one matrix key to build for bullseye and bookworm.
One last step is a cleanup step which has an if: ${{ always() }} clause.
Works normally quite well …

But: what I’ve seen is that, while the jobs are still running, If I push another new commit to gitea, then suddenly All the running jobs of that repo get canceled and the new ones start.

This even prevents the cleanup-step from triggering, so I have to do the cleanup myself.

Question is: Is this intended behavior or should I troubleshoot, why the jobs get canceled?
So far the CI-Runner doesn’t look like it has an issue … (I’m using privileged DinD with root)

greetings

I’m also interested in an answer to this.

I believe it’s related to

Also interested on this.

It’s happening both with on push and on schedule. As soon as the new push/schedule kicks in, the current job gets stopped and the new one starts.

I tried to setup a lock system, but as it stops at the same time the new one starts, it does not work.

Is there any plans to implement Github’s concurrency system?

What is the state of this?

Thanks!

Also interested on this. Does anyone know if there is any way to disable this behaviour? I want all my workflow runs to finish no matter what.

I would also like some way to disable auto-cancellation. We run set of tests when commit is pushed to main. If commits are pushed frequently enough none of the jobs can run to completion.

Also there is another problem when jobs are executed directly on a host. Normally after job is completed runner cleans it’s cache. But if job is cancelled cache stays there like forever.