The previous (v3) sync loop betrays my lack of understanding about git.
It tried to codify my archaic mental model (e.g. --branch and --rev
being disting things) and was ultimately a patchwork of corner-cases
evolved over a few years.
This commit is less of a "diff" and more of a "rewrite".
The new logic is simpler and more efficient. It does not `git clone`
ever. It does not differentiate the first sync from subsequent syncs.
It uses `git fetch` to get the exact SHA and then makes a worktree from
that.
The new `--ref` flag replaces both `--rev` and `--branch`, though it
will use those if specified. In fact, almost all of the e2e tests
passed without change - using --ref and --branch!
I will follow this commit up with more cleanups and e2es.
Thanks, bash, for supporting `<` and `>` and making them NOT mean the
obvious thing.
This shows up when you set RUNS=10:
`[[ 2 < 10 ]]` is false
`(( 2 < 10 ))` is true
Problem: Previously all of Kubernetes' image hosting has been out of gcr.io. There were significant egress costs associated with this when images were pulled from entities outside gcp. Refer to https://github.com/kubernetes/k8s.io/wiki/New-Registry-url-for-Kubernetes-(registry.k8s.io)
Solution: As highlighted at KubeCon NA 2022 k8s infra SIG update, the replacement for k8s.gcr.io which is registry.k8s.io is now ready for mainstream use and the old k8s.gcr.io has been formally deprecated and projects are requested to migrate off it. This commit migrates remaining references for kubernetes/git-sync to registry.k8s.io.
Signed-off-by: James Blair <mail@jamesblair.net>
A previous commit (2f7335868e) introduced
a quiet bug which results in the "update needed" condition triggering
every loop. e2e passed for me by sheer luck of winning races. Until it
didn't. Walking thru with the debugger to figure it out, I realized
this issue.
The short story: `ls-remote` for a tag gets us the SHA of the tag, but
`rev-parse HEAD` gets us the SHA of the commit to which that tag is
attached. Those are never equal, so we detect "update needed" every
loop.
Now we ask `ls-remote` for the rev and the dereferenced rev. If that
rev is a branch, the deref does nothing. If that rev is a tag it
produces both results. ls-remote does its own sort, so the deref (if
found) comes after the non-deref. This means that, in both cases, the
last line is the one we want.
Prior to this, it would fail if the 2nd SHA wasn't in the local repo.
Now it doesn't care what the local SHA for rev is, it only cares what is
checked out at HEAD.
Tim Hockin
Kubernetes Prow Robot
Sascha Grunert
Tommy Hyeonwoo Kim
Timothy Rule
James Blair
yoyehan