chore(CI/CD): Enable only one run per PR (cancel previous)

[rgildein]

Description

Add concurrency and group for all GitHub actions, the group name is composed:

• github.workflow — the workflow's name: field (e.g. "Lint", "Test and Code Coverage")
• github.ref — the full ref of the branch or tag that triggered the run (e.g. refs/heads/feat/my-feature, refs/pull/42/merge)

Actions cancelling prior runs on new push for all workflows, except if it's merged/pushed/tagged the main branch.

Expected output

With these changes I want to prevent running multiple jobs and save resources. Usually such situation happens during updating PR with current main branch or when I see failing lint and I push fix immediately.

[felix-kaestner]

Just as a note: We don't use semantic commits. ref/ https://github.com/ironcore-dev/network-operator/blob/main/AGENTS.md?plain=1#L53-L57

Also, I think merging back main will break the commit message validation for the 'Signed-off-by:' line. So we have to use rebase in order to bring a PR up-to-date with the latest main.

[adamtrizuljak-sap]

Both docker push and helm push should be immune to being interrupted, so I would apply the concurrency group to them as well.

Open Review.

[rgildein]

Just as a note: We don't use semantic commits. ref/ https://github.com/ironcore-dev/network-operator/blob/main/AGENTS.md?plain=1#L53-L57

The github.ref is full formatted "path" for branch name in PR. (see docs), so it's not related with commit message at all and even for branch name it does not matter if it's my-nice-brach or feat/my-nicer-branch or anything else.

Also, I think merging back main will break the commit message validation for the 'Signed-off-by:' line. So we have to use rebase in order to bring a PR up-to-date with the latest main.

This part I did not understand? One thing is that if two merge happened one after another to the main branch, already running workflows will be cancelled, so maybe we need to avoid it?

[rgildein]

Both docker push and helm push should be immune to being interrupted, so I would apply the concurrency group to them as well.

Are you sure? Already pushed layers will be removed?

[felix-kaestner]

Just as a note: We don't use semantic commits. ref/ https://github.com/ironcore-dev/network-operator/blob/main/AGENTS.md?plain=1#L53-L57

The github.ref is full formatted "path" for branch name in PR. (see docs), so it's not related with commit message at all and even for branch name it does not matter if it's my-nice-brach or feat/my-nicer-branch or anything else.

Also, I think merging back main will break the commit message validation for the 'Signed-off-by:' line. So we have to use rebase in order to bring a PR up-to-date with the latest main.

This part I did not understand? One thing is that if two merge happened one after another to the main branch, already running workflows will be cancelled, so maybe we need to avoid it?

@rgildein The comment regarding semantic commits was refering to the commit message of 56ee9c8 and the title of this PR, not the changes themselves. Regarding the comment on merging back main, I was just refering to the fact that the "Merging is blocked" gate that happens, as you merge back the main branch. I just meant that you could prevent this by using a rebase.

[adamtrizuljak-sap]

Both docker push and helm push should be immune to being interrupted, so I would apply the concurrency group to them as well.

Are you sure? Already pushed layers will be removed?

That's the responsibility of the image registry, not ours :) Best case, they auto-remove the layers from the failed push. Worst case, the layers remain there and subsequent pushes can reuse them. And helm push is just an HTTP upload of an archived file. If it breaks mid-upload, the server just ignores it.