Don't use --short when retrieving revisions from git

[dliappis]

Rally uses the git revision in several places, one of which when building Elasticsearch from source. Historically it used --short¹ which results in shorter filenames, but they are unpredictable and more importantly cause an unnecessary git clone when using the build and install subcommands separately as described in #1635.

In this commit we switch to the full SHA length for all cases.

Closes #1635

Footnotes

1. https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse
   .txt---shortlength ↩

[dliappis]

Reviewers: I spent some time thinking about what test could be meaningful for catching the referenced issue, but I can't think of a unit test that would be suitable; after all, the issue is that without this change the built artifact includes a revision that is unpredictable and possibly different from the revision passed with --revision. An IT test using a defined revision SHA IMHO would be problematic as the way that ES gets built changes over time plus it'd add unnecessary time spent building with gradle, unless we'd mock it out.

I also considered rather than removing --short SHA, to make the check more lenient; this would mean using git and therefore either cloning the repo again or using GitHub network lookups to determine whether the value passed with --revision and whatever revision value is part of the filename are the same (any of which could be a shortened version).
Cons: apart from flaky network connections, it would require knowledge of the repo URL itself which we don't store atm in the rally-teams vanicall/config.ini (the repo URL, if available, would be used for a new method to calculate the shortened revision -- e.g. see here)

Finally, this PR means that we should encourage users to pass the entire SHA when using --revision. Maybe we could strive to convert the shortened SHA to the full length SHA in a future PR?

[michaelbaamonde]

I think this is fine as-is. I appreciate the thought you put into possible test scenarios, but I agree that they're impractical.

Re: converting a short SHA to a full one in the future, it doesn't really seem worth it to me.

[dliappis]

Re: converting a short SHA to a full one in the future, it doesn't really seem worth it to me.

The motivation behind this was purely for user friendliness since some tools and UIs might emit a shortened SHA, which if passed to Rally would cause again the same unnecessary cloning described in the issue #1635 description.