Question

In relation to #1149 and the comment that one can overcome the complexities of adding a commit during the release process, how do you do configure that when I have had issues with the current recommendation from the GitHub Actions page of the PSR documentation?

Specifically, I foresee and have run into the following issues:

1. When more than a single PR is merged in rapid succession (enough to be sooner than when the previous pipeline has completed), the version commit fails to push because there is already an upstream commit on master. You would expect concurrency to prevent this but we only have concurrency set on the release job.

2. With concurrency set on the release job to cancel-in-progress, wouldn't it possibly cause corruption if it is in the middle of pushing a tag but not completing the release?

3. I could put concurrency across the entire workflow but that does not prevent a push or PR merge to have the same issue as 1.

4. I could remove the forceful checkout of the branch at the workflow sha but that re-introduces the original problem of releasing an untested change because the default branch was updated in the middle of the workflow.

Basically, when applied to PSR, there is a possibility of a push to master before the release job (during testing) and a push during the release job that could cause failures or not the desired release result? How do you overcome this?