Allow pod-utils / clonerefs to use default remote branch

[spiffxp]

My read of current pod-utils code is that it assumes base_ref to always be present / non-empty (ref: #20665 (comment))

It looks like there are 435 jobs that explicitly reference master, when what they likely mean is "just use whatever the default remote branch is"

$ ag --no-filename "base_ref:.*master" config/jobs | grep base_ref | wc -l
     435

Ideally base_ref would be auto-populated with the remote default branch if omitted. Maybe this already happens? This would make repo default branch renames less toilsome.

Opening this to track verifying or fixing, so not yet a bug or feature.

/area prow/pod-utilities

/assign @alvaroaleman @cjwagner
in case you can answer more quickly than I can, feel free to /unassign if you can't handle
/assign @spiffxp
to verify what happens today

[spiffxp]

/sig testing

[alvaroaleman]

My read of current pod-utils code is that it assumes base_ref to always be present / non-empty (ref: #20665 (comment))

Yeah, that is correct (for periodics, for presubmits/postubmits we get the info from github)

Ideally base_ref would be auto-populated with the remote default branch if omitted. Maybe this already happens? This would make repo default branch renames less toilsome.

I am pretty sure this does not happen. Adding this would be pretty easy from a complexity POV, as the default_branch is part of the repo. It will drive up token usage a bit though (and I think it won't cache that well, as the repo contains a lot of info that will regularly change, like pushed_at: timestamp, size, the number of stars, forks etc)

[spiffxp]

If we're concerned about token usage, we could try doing this directly in clone by using the contents of .git/refs/remotes/origin/HEAD if base_ref is empty. I dunno if that makes the API feel too weird though (technically it does omitempty as-is)

[spiffxp]

/area jobs
since this would be a job config change too

[spiffxp]

/wg naming
since this is in support of kubernetes/org#2222