## Wheel Test

This directory is dedicated to tests that require a built TensorFlow wheel
file for testing, such as:

* Ensuring the entire API is importable
* Testing downstream projects against the wheel

Ensure you have Bazel installed and accessible from your command line.

These tests use hermetic Python. They also require a built TensorFlow wheel file
and a requirements_lock file. The requirements_lock file is generated by the

# it enables a derived --config setting.  If RBE is not available (i.e. there
# is no --config setting), bazel would fail and quit. This script does a quick
# check This script checks for such errors early
if ! grep "rbe_$TFCI_BAZEL_TARGET_SELECTING_CONFIG_PREFIX" .bazelrc; then
  cat <<EOF
ERROR: RBE was enabled via the 'rbe' env in the 'TFCI' variable.
       TFCI: $TFCI

export TF_VER_PATCH=$(awk '/#define TF_PATCH_VERSION/ {print $3}' tensorflow/core/public/version.h)

# Note: in awk, "print $N" prints the Nth "field", where fields are strings separated
# by whitespace. The flag "-F<x>" changes the behavior such that fields are now strings
# separated by the character <x>. Therefore, -F\' (escaped single quote) means that field
# $2 in <Tensor'flow'> is <flow>. This is useful for reading string literals like below.

### Typical Pull Request Workflow -

**1. New PR**

- As a contributor, you submit a New PR on GitHub.
- We inspect every incoming PR and add certain labels to the PR such as `size:`,
  `comp:` etc.  At this stage we check if the PR is valid and meets certain
  quality requirements. For example, we check if the CLA is signed, PR has

// A handle to a tensor on a device.
//
// Like a TF_Tensor, a TFE_TensorHandle refers to a tensor with a value, shape,
// type etc. Unlike a TF_Tensor, a TFE_TensorHandle may refer to such tensors
// placed in the memory of different devices or remote address spaces.
typedef struct TFE_TensorHandle TFE_TensorHandle;

TF_CAPI_EXPORT extern TFE_TensorHandle* TFE_NewTensorHandle(const TF_Tensor* t,

#   your builds. This usually saves a lot of time, especially when
#   re-running tests. However, note that:
#
#    - New environments like new CUDA versions, changes to manylinux,
#      compilers, etc. can cause undefined behavior such as build failures
#      or tests passing incorrectly.
#    - Automatic LLVM updates are known to extend build time even with
#      the cache; this is unavoidable.
export TFCI=py311,linux_x86,public_cache,disk_cache

        return;
      }
      // We have a convoluted scheme here: Using the C++ graph construction API
      // to add potentially many nodes to the graph without running the checks
      // (such as uniqueness of the names of nodes) we run with other functions
      // that add a node to the graph (like TF_FinishOperation).
      if (!g->name_map.insert(std::make_pair(n->name(), n)).second) {

    int64_t init_timeout_in_ms, TF_Status* status,
    bool clear_existing_contexts);

// Set server def with retries and timeout. This is helpful for fault-tolerant
// initial connection in high-preemption environments, such as
// ParameterServerStrategy training.
// This API is for experimental usage and may be subject to change.
TF_CAPI_EXPORT extern void TFE_ContextSetServerDefWithTimeoutAndRetries(

targets of those operations, which could result in arbitrary
read/write/executions.

### Running a TensorFlow server

TensorFlow is a platform for distributed computing, and as such there is a
TensorFlow server (`tf.train.Server`). The TensorFlow server is intended for
internal communication only. It is not built for use in untrusted environments
or networks.

  DEVICE_PLACEMENT_SILENT_FOR_INT32 = 3,
};
// LINT.ThenChange(//tensorflow/c/eager/c_api.h)

// Abstract interface to a context.
//
// A context is responsible for creating key objects such as Tensors,
// TensorHandles & Operations.
class ImmediateExecutionContext : public AbstractContext {
 public:
  // Optimized scalar creation functions
  virtual AbstractTensorInterface* CreateInt64Scalar(int64_t value) = 0;