Add cancel-in-progress

[erikbosch]

Intention is to cancel ongoing/queued jobs if a new version of a PR is uploaded

Fixes #626

[erikbosch]

General idea is to have a unique group-id for each job. I first tried including ${{ github.job }} but that is not set when this is evaluated, so now the pattern is ref-workflow-

[erikbosch]

This is an example of what happens if a job is cancelled because a new PR version has been uploaded

[lukasmittag]

couldn't we put it one layer up on the same level as jobs? because if one workflow will have one with a higher priority it will cancel all and we need less code. Should work too according to the docs.

[erikbosch]

couldn't we put it one layer up on the same level as jobs? because if one workflow will have one with a higher priority it will cancel all and we need less code. Should work too according to the docs.

I tried to put the concurrent on workflow level like below, but then the cancel-in-progress seemed to cancel all but one of the jobs in that workflow. Will test a bit more

 concurrency:
      group: ${{ github.ref }}-${{ github.workflow }}
      cancel-in-progress: true

[erikbosch]

couldn't we put it one layer up on the same level as jobs? because if one workflow will have one with a higher priority it will cancel all and we need less code. Should work too according to the docs.

I think I found the problem of having concurrency defined on workflow level - we can have it for all but the check_push_right workflows, as that is a reusable workflow. Also no need on that one as it is a very quick one, the biggest gain is in our "lengthy" workflows, especially the ARM ones

[SebastianSchildt]

Looks good to me, and everything is green

If an actual (sequence of) cancel(s) later leads to some unforeseen problems, we will see and can fix it then :)