In particular, I think chrome-side devs (and maybe chrome-side infra?) expect that it will be updated every time they sync chrome.

But it doesn't update automatically in chromeos, nor is there a test or monitoring that would let us know when it gets stale.

Tagged with both infra components - can you guys discuss and figure out the right thing to do here?

s/you guys/both infra teams/

the only things we care about in depot_tools anymore on the CrOS side are linters (cpplint.py & pylint) and gclient.

on the dev side, we normally expect people to get their own depot_tools checkout.  they have to normally anyways -- it's how you get `repo` and `cros_sdk` in order to get a CrOS checkout & a CrOS chroot.

so i wonder why devs are using the depot_tools that is part of the CrOS checkout instead of the one they should have made independently.

we don't have any infrastructure today to support auto-updating the manifest repos.

Apparently a script called "cros_best_revision.py", which runs on a builder and not on a dev workstation, implicitly relies on "git_cl.py" from depot_tools.

https://cs.corp.google.com/chromeos_public/chromite/scripts/cros_best_revision.py?q=cros_best_revision&sq=package:%5Echromeos_public$&l=1

 Issue 618430  describes the most recent problem with cros_best_revision.

Yeah, as an individual developer my depot_tools auto-updates and works fine. I'm just not sure what to do to prevent breakage on bots like  issue 618430 .

What version of depot_tools gets deployed to the builders, and how?

There are two copies we care about.

Our recipe checks out a pinned version that is available in the PATH when outside the chroot. It's pinned here:

https://cs.chromium.org/chromium/build/scripts/slave/recipe_modules/chromite/api.py?rcl=7ff6cd1ac8a56099c02391904b2fd2c37fff1efe&l=13

The ChromeOS manifest also includes a copy of depot_tools, which is pinned in the manifest.

I'm not certain, but I suspect that the manifest version is the only version available inside the chroot, and that outside the chroot we use a combination of commands from PATH (especially 'repo' and 'cros_sdk'), and commands from the manifest invoked with an explicitly.

We don't have any coordination between the recipe and manifest pins of depot_tools.

yes, the version that is in the manifest is the one that's used inside the sdk

- chromite/scripts/cros_sdk.py sets the DEPOT_TOOLS env var to the path in the manifest when launching the enter chroot script
- src/scripts/sdk_lib/enter_chroot.sh uses that env var to bind mount it to /mnt/host/depot_tools
- tools will either use that path directly or (in the case of chromite) use the original source path under ~/trunk/

FYI chrome is now provided a pinned version of depot_tools in src/third_party/depot_tools. I think chrome infra people are trying to migrate everyone to that, then the external "depot_tools" will eventual just become bootstrapping scripts to get your first checkout.

Pinning "depot_tools", especially for downstream projects, is good, but I think CrOS is already doing this. We do have plans to modify the repository over time to trim and adapt it from the huge buffet that it is down to a few tailored plates.

That said, uprevving is not a bad idea. The repository changes, and will probably more now that it's not cripplingly scary since Chrome pins it. Just make sure you CQ the uprevs.

A very, very long time ago, I forked the bootstrap scripts required for a ChromeOS Brillo build into chromite/bootstrap. They were flat copies which haven't been updated, but also haven't been deleted (vapier stopped me).

These are the wrappers developers required at that time to setup/build brillo without depot_tools:
  cbuildbot cros  cros_sdk repo

Throwing this out as an option to remove one depot_tools pin, though having those forked tools be used would make me nervous.

This bug is very old, is Untriaged, and has no owner.  If it is still relevant, reopen as Untriaged or open a new bug