Github CI concurrency seems to cancel runs due to priority quirks

[axel-h]

Github CI concurrency seems to cancel runs due to priority quirks

[lsf37]

If we want to avoid that, we need to encode something like the PR number in the concurrency statement here.

This might be as simple as

concurrency: camkes-hw-pr-${{ github.event.number }}-${{ strategy.job-index }}

[lsf37]

(We'd need to check that the event number stays the same when new commits are pushed to the PR)

[axel-h]

We could also remove the concurrency field. In the kernel Hw run it also does not exist. If the machine queue serialized things that would do. Just for multiple pushed to a PR, having never pushe killing the runs of older one might be useful - or in some cases not as one might want the older runs to finish to see some intermediate results.

[lsf37]

We could also remove the concurrency field. In the kernel Hw run it also does not exist. If the machine queue serialized things that would do.

The idea is to reduce load on the machine queue. It would still run all the old jobs that are not interesting any more and block the boards for other things during that time. If at all, I would want to add this to the kernel HW run as well when it works properly.

Just for multiple pushed to a PR, having never pushe killing the runs of older one might be useful - or in some cases not as one might want the older runs to finish to see some intermediate results.

For that case (where we do want intermediate results) I think we should then wait with the push instead of pushing multiple times and always processing everything. For some boards there is only one in the machine queue, and multiple PRs can easily amount to > 100 jobs (20-ish per run), which means most of them will just be waiting on lock for a very long time and progress will be slow for most of them.