I am looking at implementing semantic-release in my GitLabCI build process, for a C++ application. However I'm concerned about potential race conditions.
Firstly, if two builds are running concurrently, both with the same kind of version increment type in the latest commit, what is to prevent them both being assigned the same version number by semantic-release? Will semantic-release do a git tag refresh just prior to assigning a version number in case the version it was going to assign has been poached?
Secondly, I need to compile the version number into the binary, so I need semantic-release to give my process an available version number at the start of the process, then reserve that for the entire build process (~1 hour), then publish that version at the end of the successful build. I can see that semantic-release supports a dry-run mode that will give the proposed version number, which my process can capture. However I can't see any way for semantic-release to reserve a version number during the build process, so another process could begin and take the same version number, then succeed earlier (for whatever reason), and cheat the first process out of the version number it claimed.
So given these situations, does semantic-release support any mechanism for reserving version numbers to avoid these kinds of race conditions?
You can achieve everything you need by using atomic-release.
Check out the example of using gitSemanticRelease
Using that, you have complete access to the version whenever you need to.