Bug: Mage workflows are being canceled

[bendiknesbo]

When using the goapp.yaml workflow, and merging PR-1 which contains Go-changes, then merge PR-2 which does not contain Go-changes, the building&publishing of the OCI images is cancelled.

1. I merge a PR with a change to Go code
   a. This starts a new run of mage-ci on main, to build the OCI image
2. I then merge another unrelated PR that does not change any Go code (e.g. a docs-PR)
   a. This starts a new run of mage-ci on main, and skips the Go application job, and cancels the previous run of mage-ci

[bendiknesbo]

From @AtzeDeVries on slack:

I think we have to look using a fallback when on the main branch
https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency#example-using-a-fallback-value
Where we use the pr number with some stuff tied to the workflow and a fallback is the run_id
It looks like the pr number is not available when on main and so it uses the run_id which is always uniq. We never want to cancel or skip a run on main

[AtzeDeVries]

According to Gemini 3

what about reusable workflows? If a concurrency is defined in the reusable workflow will it override the concurrency in the calling workflow?

No, the concurrency in a reusable workflow does not automatically override the concurrency in the calling workflow
. Instead, both settings apply independently, which means a workflow run can be subject to multiple concurrency checks.
🤝 How They Interact
The two concurrency settings manage different scopes and locks:

The calling workflow has its own concurrency setting (either at the workflow level or job level, for the job that calls the reusable workflow). This controls the concurrency of the caller's overall workflow run or that specific job within the caller.
The reusable workflow can also have its own workflow-level concurrency setting, which controls the concurrency of any instance of that specific reusable workflow being called, regardless of which caller is using it.

Potential Conflict Scenario
It is important to be mindful of potential conflicts, especially if you use the same concurrency group name in both the caller and the callee workflow.
For example, using an expression like ${{ github.workflow }} in the concurrency group name is tricky:

In the caller workflow, ${{ github.workflow }} refers to the caller's filename.
In the reusable workflow, when called, ${{ github.workflow }} also refers to the caller's filename, not its own. 

If both workflows use the same dynamic expression for their concurrency groups and cancel-in-progress: true is set, they can end up canceling each other out, resulting in a loop where no workflow successfully finishes.
Best Practices

Define concurrency at the most appropriate level:
    If you want only one instance of a shared, critical process (like a production deployment) to run at a time, define concurrency within the reusable workflow itself at the workflow level.
    If you need to limit how many times a specific job within the caller can run, define concurrency at the job level in the calling workflow.
Use distinct group names: Ensure concurrency group names are specific enough (e.g., using different prefixes) to avoid unintended conflicts between the caller and the called workflow. 

For more details, the GitHub documentation on reusing workflows provides information on how these settings interact.