Can't specify a commit hash instead of a branch name

[Jawshua]

Hey there,

One feature that would be good is the ability to target runs against a specific commit rather than a branch, which would be useful when kicking off automated testing on a busy branch. Currently when you attempt this it will throw out an error that looks something like this:

Build aborted due to error: Could not fetch specified branch "asdasdasdasdasd" from remote "origin". Command: "git fetch --update-head-ok origin asdasdasdasdasdasd" Output: ""

Looking at the git runner source it seems like this may have been in the roadmap at some point, but I couldn't find an issue for it.

[josephharrington]

We actually did support this functionality at one point but it was removed in #302, ostensibly to make the implementation of shallow cloning simpler. But @Jawshua I agree with you that ClusterRunner should support this functionality.

Since the ClusterRunner master creates its own local ref for slaves to clone from (and since the master always does a non-shallow clone), it would be trivial to support both a commit hash parameter and shallow clones on the slaves assuming the slaves are cloning from the master. I think we should implement this.

If the slaves are not cloning from the master, it would be a bit trickier -- something like having the master tell the slave what depth to clone/fetch the specified ref (plus some buffer since that approach would still be susceptible to race conditions, and that strategy starts to sound like it's more trouble than it's worth).

A workaround/alternate approach to running on guaranteed specific hashes (which we do internally at Box for some use cases) is to have automation push a ref to the remote (e.g., git checkout mybranch && git push origin HEAD:refs/temp-refs/$(git rev-parse HEAD) and then trigger the clusterrunner build on that ref.

[Jawshua]

In my setup the slaves do indeed clone from the master, so it's good to know that this would potentially be possible. Would you require an implementation to support both master and non-master clones for it to be considered?

The temporary ref branch is something I'd considered already, but I wanted to avoid adding more noise to our git activity feed channel if possible.

[josephharrington]

I think it would be fine to only support passing in a hash when cloning from the master, as long as the behavior in the non-master-clone case was sensible (maybe fail the build with an error mentioning the get_project_from_master conf setting or something like that).

[tjlee0909]

I'm fine with that incremental solution, which is to just support specifying a hash within a branch for the master-clones first, with a sensible error message--and later figuring how to support it for slaves that clone directly from the source.