There is currently no such mechanism. However, I am hesitant to go with this option, namely because disabling something indefinitely is the sort of thing that tends to last indefinitely.

I implemented a CL that solved all of the issues that we talked about on Friday - notably on your list, "clone" retries. How difficult would it be to add the wrapper to "chroot" and call that a victory?

(I CC'd you on the CL, but just in case: https://chromium-review.googlesource.com/c/479459/ )

Chroot solutions:

1) Decide it's okay to not have the wrapper inside the chroot.

Easiest, if we can show we don't use git from inside the chroot, and prove that going forward. Might be as easy as adding an assert to repository.py and git.py.

2) Copy binary into chroot via cros_sdk script.

Somewhat hacky, since builder configuration specific stuff makes it into the chroot generation code. Similar issue to how we are handling goma, which involved touching many layers of code.

Some generic cipd inside the chroot solution would be good here, but branching makes it tricky.

3) Use ebuild to install binary into chroot.

How we normally manage things. It's probably not super hard because the source is already on the chromium GoB, though there are pinning/branching questions to decide. It would mean we have independent versions of the wrapper inside and outside the chroot, and environmental variables would be tricky to handle, going forward.

Does "chroot" use system Git or bundle its own? I think the latter, so (3) would make sense here. How about "chromite" - does "chroot" actually have its own "chromite", or does outer "chromite" call "chroot" functions and perform the retry on them?

when you say "binary", do you actually mean a precompiled binary ?  we don't like that as a general thing, especially if we have the source.  if it's just building some go project and installing the results, we should be able to write an ebuild to do that.

wrt git usage inside the chroot, i don't know the answer there.  we have in the past (via git eclasses), but we probably do with chromite too (although not a git clone operation which i think is all you care about).

the CrOS sdk builds & installs its own version of git from upstream.
https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/master/dev-vcs/git/

wrt chromite, there is only one source repo active in the build ... the one part of the repo sync (ignoring the weird bootstrap logic we have to integrate with buildbot).

Is "clone" special here? If "cbuildbot" does all of the network activity, it's possible that "chroot" Git doesn't even do any network operations, so there isn't anything to transiently care about.

we've had ebuilds do network based git clones in the past.  it's not something we want though, so when it happened, we fixed the ebuild.

Ah, makes sense. Then yeah I think having the wrapper in and on PATH seems valuable.

Oh the other hand, if you have ebuilds that cloned in the past, they probably didn't have any transient failure protection, meaning that you're not losing anything by *not* having the wrapper installed.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".