Make ES clone target fall back to master

[jasonrhodes]

I've noticed this issue coming up a bunch in the last couple weeks in various channels, so I wanted to explore this option. @tylersmalley had concerns when I first brought it up but I don't remember them exactly, so I thought it'd be nice to have those documented here in GH.

Basic problem is: if you create a branch like elastic/kibana:big-feature, then a few people create small branches that are meant to merge into the feature branch before going to master etc, kibana won't build because of how it tries to find the elasticsearch repo based on your PR branch name and the PR target/base branch name.

Example
PR branch: jasonrhodes/kibana:add-fun-stuff
PR base/target branch: elastic/kibana:big-feature

Jenkins build fails, tries to look up the following:

07:18:21  -> checking for 'add-fun-stuff' branch at jasonrhodes/elasticsearch
07:18:22  -> checking for 'add-fun-stuff' branch at elastic/elasticsearch
07:18:23  -> checking for 'big-feature' branch at elastic/elasticsearch
07:18:24  -> checking out 'big-feature' branch from elastic/elasticsearch...

The last line of those logs there will fail because big-feature is not a branch on the elastic/elasticsearch repo.

The only way to fix this right now is to create a "shadow branch" in your own fork of ES, so I would create jasonrhodes/elasticsearch:add-fun-stuff and Jenkins would find that branch on my fork in its first search and use it. This PR just proposes to add one last check if it doesn't find any of these branches anywhere, it falls back to elastic/elasticsearch:master.

If you are doing anything out of the ordinary where you need to test against a specific version of ES, you can then make your shadow branch in your ES fork and it will still work the way it does now, but in what I think is the majority of cases, where a Kibana PR doesn't have corresponding ES changes, the build will "just work".

Thoughts? cc @epixa @tylersmalley (not sure who else should be pinged on this so feel free to add)

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[epixa]

This approach seems reasonable to me. We don't necessarily know that the feature branch is against master, but when we have a long running feature branch like this, it almost certainly is against master. In the rare event that you are PRing to a long running feature branch that isn't based on master, then ci will fail due to version mismatch, and the solution will be the same hacky workaround that we're telling people today (pushing an equivalent branch to your ES fork).

If we want to make this really comprehensive, we could parse out the branch identifier from package.json via a node command.

[tylersmalley]

Looks like this was merged as part of the InfraOps PR: #24068