)]}'
{
  "commit": "2543e6558f48c5acf5fcd12f447c872f02aa2a49",
  "tree": "e5aeeece4f74a2832d7faacca2ba730d10222bcd",
  "parents": [
    "5d853e3e6d8b306e8843992bc8f74089f3f8a6ca"
  ],
  "author": {
    "name": "Evan Brown CA",
    "email": "ezb@google.com",
    "time": "Tue Oct 20 11:44:51 2026 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Tue Oct 20 12:32:00 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: 1003271781\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"
    }
  ]
}