Cancel concurrent CI workflow runs

[pabzm]

Here's another attempt at reducing duplicated CI workflow jobs, which in my understanding should not impair forks.

@mvorisek I'd like to hear your opinion, too.

(For context, the previous attempt was #9942)

[mvorisek]

I really hate canceling workflows, if I push multiple commits after each other, I want CI for each, sometimes I use CI to test something. With this PR landed, I would have to wait between the pushes.

So -1 from my side. My mantra is to utilize resources to save humans, not the other way around. CI is cheap and cheaper every year :)

[pabzm]

@mvorisek This cancels jobs only if the job name and the git ref are identical. So for subsequently pushed commits it should still run one job per commit, as far as I understand. Is that your understanding, too?

I understood that you don't consider this worthwhile, you made that point. Please accept that I do consider it worthwhile and would like to reduce the waiting time.

[mvorisek]

This cancels jobs only if the job name and the git ref are identical.

What scenarios exactly this cancels jobs for then?

[alecpl]

Doesn't the problem exist only in PRs from a local branch? Maybe just stop using local branches. BTW, we should start removing branches that were used for PRs and aren't needed anymore.

[pabzm]

What scenarios exactly this cancels jobs for then?

E.g. in this PR, each job runs twice, here's a screenshot:

The change of this PR would cancel one of each duplicate jobs (without marking it as failed).

Doesn't the problem exist only in PRs from a local branch?

With "local" you mean a branch from this repo? That might be the case, I'm not sure.

Maybe just stop using local branches.

No, I consider it good practice to work in branches in the repo. I'd prefer not to argue about the "correct" way to work with branches, but instead allow each of us to do as we want to – that's why I closed #9942, and am proposing a different way.

we should start removing branches that were used for PRs and aren't needed anymore.

Yes, indeed. Unfortunately for all squash- and rebase-merges there's no automatic way to filter the merged branches, so it'll be a lot of manual work. I'll do some once in a while.

[pabzm]

I enabled the option "Automatically delete head branches" (as described on https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches) in this repo, maybe it helps for the future.

[mvorisek]

If you want to work with the repo this way, you can achive the wanted behaviour with condition like zopefoundation/meta#145 (comment).

[pabzm]

Would it be another option to restrict jobs to 1. pushes to the "master" branch, and 2. pushes to branches that have a pull request against the "master" branch?

Like this:

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master  

This would only not work for development in branches without a pull requests. Do you need those?

[pabzm]

If you want to work with the repo this way, you can achive the wanted behaviour with condition like zopefoundation/meta#145 (comment).

Thank you for the suggestion! We already have an if-clause (matching "[skip ci]"), so extending those would result in a very long line. But if there's a reason not to pick my other suggestion then maybe it could still be the way to go.

[mvorisek]

The #9997 (comment) is not good, as pushes to non-main repo branches should not be name based/restricted.

[pabzm]

Closing in favour of #10008