pull requests are approved and pass continuous integration checks, a TensorFlow
team member will apply `ready to pull` label to your change. This means we are
working on getting your pull request submitted to our internal repository. After
the change has been submitted internally, your pull request will be merged
automatically on GitHub.

If you want to contribute, start working through the TensorFlow codebase,
navigate to the

        map sigbuild-r2.17-clang-python3.11 2.17-python3.11
        map sigbuild-r2.17-clang-python3.12 2.17-python3.12
    - name: Create Pull Request with changes
      uses: peter-evans/create-pull-request@2b011faafdcbc9ceb11414d64d0573f37c774b04 # v4.2.3
      with:
        title: Update the RBE images to the latest container versions

#       ...
#       ./any.sh
#     or
#       export TF_ANY_EXTRA_ENV=ci/official/envs/local_rbe
#       ./any.sh
#       ...
set -euxo pipefail
cd "$(dirname "$0")/../../"  # tensorflow/
# Any request that includes "nightly_upload" should just use the
# local multi-cache (public read-only cache + disk cache) instead.
export TFCI="$(echo $TFCI | sed 's/,nightly_upload/,public_cache,disk_cache/')"

    # via -r requirements.in
certifi==2024.2.2 \
    --hash=sha256:0569859f95fc761b18b45ef421b1290a0f65f147e92a1e5eb3e635f9a5e4e66f \
    --hash=sha256:dc383c07b76109f368f6106eee2b593b04a011ea4d55f652c6ca24a754d1cdd1
    # via requests
charset-normalizer==3.3.2 \
    --hash=sha256:06435b539f889b1f6f4ac1758871aae42dc3a8c0e24ac9e60c2384973ad73027 \
    --hash=sha256:06a81e93cd441c56a9b65d8e1d043daeb97a3d0856d177d5c90ba85acb3db087 \

                                                 TF_Status* status);

// Sync pending nodes in local executors (including the context default executor
// and thread executors) and streaming requests to remote executors, and get the
// combined status.
TF_CAPI_EXPORT extern void TFE_ContextAsyncWait(TFE_Context* ctx,
                                                TF_Status* status);

# For release jobs, we will pin these on the release branch
keras-nightly ~= 3.0.0.dev
tb-nightly ~= 2.17.0.a

# Test dependencies
grpcio >= 1.24.3, < 2.0
portpicker == 1.6.0
scipy == 1.11.3
requests == 2.31.0
packaging==23.2
setuptools==68.2.2

    # via -r requirements.in
certifi==2024.2.2 \
    --hash=sha256:0569859f95fc761b18b45ef421b1290a0f65f147e92a1e5eb3e635f9a5e4e66f \
    --hash=sha256:dc383c07b76109f368f6106eee2b593b04a011ea4d55f652c6ca24a754d1cdd1
    # via requests
charset-normalizer==3.3.2 \
    --hash=sha256:06435b539f889b1f6f4ac1758871aae42dc3a8c0e24ac9e60c2384973ad73027 \
    --hash=sha256:06a81e93cd441c56a9b65d8e1d043daeb97a3d0856d177d5c90ba85acb3db087 \

    now served with tensorflow/serving, it will accept requests using 'inputs'
    and 'outputs'. Starting at 1.2, such a model will accept the keys specified
    during export. Therefore, inference requests using 'inputs' and 'outputs'
    may start to fail. To fix this, either update any inference clients to send
    requests with the actual input and output keys used by the trainer code, or

    // more than fits in a 32-bit integer.
    size_t requested_read_length;
    if (n > INT32_MAX)
      requested_read_length = INT32_MAX;
    else
      requested_read_length = n;

    // `pread` returns a `ssize_t` on POSIX, but due to interface being
    // cross-platform, return type of `Read` is `int64_t`.
    int64_t r = int64_t{pread(posix_file->fd, dst, requested_read_length,

permissions:
  contents: read

jobs:
  close-issues:
    # Don't do this in forks
    if: github.repository == 'tensorflow/tensorflow'
    runs-on: ubuntu-latest
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Awaiting response issues
        uses: actions/stale@6f05e4244c9a0b2ed3401882b05d701dd0a7289b # v7.0.0
        with: