Draft: When accepting a merge request, include VersionNum updates in binaries
At this point, GitLab launches a non-detached pipeline, but does so using
the SHA from before srccommit did its thing to update the VersionNum (because
this is performed using a hook at the git level that GitLab knows nothing
about). The result is that the last artifacts presented on the MR page still
have the version numbers at their pre-increment state. It's still possible
to autobuild binaries with the new version number by manually launching a
pipeline afterwards, but that's an extra step for a human to perform and so
is undesirable.
To attempt to deal with this, introduce a check on the environment variable
CI_COMMIT_BRANCH. This is only set when the pipeline was launched based on
a branch ref, and appears to include the case when an MR has just been
merged. If so, we assume the origin remote contains a more up-to-date
version of this branch ref (i.e. one with VersionNum updated) so we check
that out before commencing the rest of the build steps.
When launching a pipeline manually on a branch ref, this additional step should have no effect.
I definitely think it's worth testing this MR on an offline GitLab installation before merging it - can you help with this @jbyrne? It's just the sort of thing I can imagine GitLab screwing up, especially with a forked workflow, for example in cases where the same branch ref exists (pointing at different commits) in the fork project vs the upstream project.