tensorflow/toolchains

Bazel toolchain configurations used across TensorFlow ecosystem

TensorFlow Toolchains (DEPRECATED)

The TensorFlow toolchains have moved to the main TensorFlow repository. See tensorflow/tools/toolchains.

toolchains's Issues

Proposal: Automation for RBE & toolchain updates w/ SIG Build dockerfiles

This is a brief proposal about how to streamline the toolchain release process. Considering this background information:

• The SIG Build dockerfiles work with RBE, and we can probably work on replacing our current containers with those
• There are workflows that automatically build the SIG Build containers and push them to:
  • gcr.io/tensorflow-sigs/build:r2.N+1-python3.X, e.g. the current N+1 TF release in tensorflow/tensorflow@master is 2.9, so we have r2.9-python3.X` containers
  • gcr.io/tensorflow-sigs/build:prnumber-python3.X, updated every time a PR made by an internal TF dev pushes to their development branch

Consider a process like this:

1. The workflows above push the new containers to gcr.io

2. The same workflow automatically updates relevant hashes in the toolchains config file

   We could have something like this:

   # each set of "configs" shares the same env settings; we'd only need the multiple-repo
   # functionality if we're providing more than one RBE Python environment. There would be
   # one of these blocks for each TF version since we started this setup; we'd only ever update
   # the WIP PR ones, and then the N+1 version when merged. So old versions would always
   # be still set to match whatever they were when the branch was cut
   sigbuild_tf_configs(
       { 
           # The default toolchain doesn't have a "python" name attached, we'd just decide on a container to set for it.
           # The toolchain by itself doesn't actually refer to a specific Python version, so it doesn't make sense to specify
           # one, except to set a different container here for use with RBE.
           "sigbuild-r2.9": "docker://gcr.io/tensorflow-sigs/build@[latest default hash]",
           # Here are different toolchains for use with non-default RBE settings.
           # The DevInfra team actually only uses one container so I'd rather not have these at all, but apparently
           # downstream users might use them? 
           "sigbuild-r2.9-python3.7": "docker://gcr.io/tensorflow-sigs/build@[latest python3.7 hash]",
           "sigbuild-r2.9-python3.8": "docker://gcr.io/tensorflow-sigs/build@[latest python3.8 hash]",
           "sigbuild-r2.9-python3.9": "docker://gcr.io/tensorflow-sigs/build@[latest python3.9 hash]",
           "sigbuild-r2.9-python3.10": "docker://gcr.io/tensorflow-sigs/build@[latest python3.10 hash]",
       }
       env = {...}
   )
   
   # A CUDA or manylinux container example
   sigbuild_tf_configs(
       {
           # IF this is set here, then the hash gets updated whenever PR #67 to SIG Build gets updated.
           # Otherwise the automation does nothing
           "sigbuild-67": "docker://gcr.io/tensorflow-sigs/build@[latest "PR #67" hash]",
       }
       env = { different CUDA settings, or manylinux2014, etc.}
   )

3. The workflows automatically merge the PR to this toolchains repository (optional, could do this manually instead), cut a new release, and upload the new release to TF mirror (this is probably doable with proper credentials. If not, this may need to be manual)

4. The workflows create a PR to TensorFlow updating the toolchains dependency, which must be approved and merged by a human.

This process depends on us being able to implement the automation as specified, but I think we could do most of it. We'd end up with a very easy RBE update process. When adding a new version, the changes to TensorFlow's bazelrc would still be manual, but that's only once per release. We'd also then be able to trash old configurations related to the versions of TF we don't support any more.