Description
@nunit/engine-team
I'm elaborating on this issue quite a bit so everyone can be aware of the problem and also so we can select the best direction to go.
I've seen a number of unexpected failures, where publishing of a build was skipped unexpectedly. Investigation shows that this happens when the HEAD of the branch on which the workflow is being run already has a tag. In that case, GitHub actions switches to the tag and our scripts no longer see the actual branch name and take the tag reference as an indication of the version to be built. For example, a tag in the form 1.5.0-alpha.4 is presented to our cake script as 1.5.0-tags-1.5.0-alpha.4. Since tags is not a pre-release label we publish, no publishing is done.
We could fix this in a number of ways. The simplest might be to simply stop tagging our alpha buillds. The alpha versioning would then exist on the myget feed but would not be visible in the repo itself. This is how things used to work back when we used dev as the label. Adding the tags seemed like a good idea at the time, but their loss may not be a big problem. If we took this approach, then the only tags that would be added would be those done manually by the developer and the tag added by GitHub when a release is published there.
Alternatively (or additionally) we could parse the tags we find to determine the version of the current head. Using the initial example, we would recover the version 1.5.0-alpha.4 from the tag. This may, in fact be needed to deal with the situation where a tag has been applied manually in order to force a version change. Testing will be required.
I think there are other possibilities, including treating this situation as an error, thereby requiring a fresh commit with some change in order to produce a new version. We could also accept it as a "feature" since it disallows the republication of any version already tagged and published.
I'd appreciate your thoughts on which way to go on this.