Expand components version specification format to allow branches
What does this MR do?
Expand components version specification format to allow branches to be checked out.
Currently we specify versions for Gitlab-Shell, Workhorse and Gitaly using version strings, to which we prepend 'v' and assume are tags. These changes allow branches or tags with other name formats to be specified by prepending '=' to the version string (á la govendor).
We also simplify the process to reset to the given version (now a branch or tag): Right now there's a check to supposedly try to avoid fetching from the remote the version if it already exist locally. But the previous logic already clones if the directory doesn't exist or fetches if it does, so this check is pointless. We can safely assume the version exists once we get to the reset stage.
Are there points in the code the reviewer needs to double check?
No
Why was this MR needed?
During development it's useful to specify an untagged version of a repo for it to be used for CI and local testing.
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master(if it does - rebase it please) -
Squashed related commits together