)]}'
{
  "commit": "c3d4bbb187f90f8610483f2d2c51d26c2ed062f5",
  "tree": "20b1fe25b66b2d8cd5a5f1ae4618c413e3c9aad2",
  "parents": [
    "35cb2992a9281e5c6261f9706384f1b5fa163898"
  ],
  "author": {
    "name": "Evan Brown CA",
    "email": "ezb@google.com",
    "time": "Tue Oct 20 14:33:33 2026 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Tue Oct 20 14:34:10 2026 -0700"
  },
  "message": "Pin vendored Bazel repositories in `macos_xcode_bazel.sh`.\n\n`abseil-cpp_vendor.tar.gz` is generated on Linux, and Bazel\u0027s `.marker` files in the vendor directory record a predeclared input hash that includes the host OS name and architecture. When `macos_xcode_bazel.sh` runs on macOS with `--vendor_dir`, Bazel treats every vendored repository as out-of-date and falls back to downloading external repositories from GitHub over the network. With `common --http_connector_attempts\u003d10` and `common --http_timeout_scaling\u003d2.0` in `.bazelrc`, when a macOS Kokoro VM encounters blackholed connections or DNS failures reaching `github.com`, Bazel retries each failed repository fetch with exponential backoff for over an hour (~60–90 minutes) before failing the build.\n\nAppend `pin(\u0027@@\u003crepo\u003e\u0027)` entries to `VENDOR.bazel` after extracting the vendor archive so Bazel uses the vendored repository contents directly without checking the Linux-generated `.marker` hashes or attempting network downloads.\n\nPiperOrigin-RevId: 1003400638\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "54d06eb66544fc7d7f1d12420813b27591c35466",
      "old_mode": 33261,
      "old_path": "ci/macos_xcode_bazel.sh",
      "new_id": "a45d353bdefb37c14a6f738ead4631d84481a00e",
      "new_mode": 33261,
      "new_path": "ci/macos_xcode_bazel.sh"
    }
  ]
}