* graphBuilder.incidentEdgeOrder(ElementOrder.stable())}.
   *
   * <h3>In combination with {@code incidentEdgeOrder}</h3>
   *
   * <p>{@code incidentEdgeOrder(ElementOrder.stable())} guarantees the ordering of the returned
   * collections of the following methods:
   *
   * <ul>
   *   <li>For {@link Graph} and {@link ValueGraph}:
   *       <ul>
   *         <li>{@code edges()}: Stable order

   * graphBuilder.incidentEdgeOrder(ElementOrder.stable())}.
   *
   * <h3>In combination with {@code incidentEdgeOrder}</h3>
   *
   * <p>{@code incidentEdgeOrder(ElementOrder.stable())} guarantees the ordering of the returned
   * collections of the following methods:
   *
   * <ul>
   *   <li>For {@link Graph} and {@link ValueGraph}:
   *       <ul>
   *         <li>{@code edges()}: Stable order

   *
   * <p>The default value is {@link ElementOrder#unordered() unordered} for mutable graphs. For
   * immutable graphs, this value is ignored; they always have a {@link ElementOrder#stable()
   * stable} order.
   *
   * @throws IllegalArgumentException if {@code incidentEdgeOrder} is not either {@code
   *     ElementOrder.unordered()} or {@code ElementOrder.stable()}.
   * @since 29.0
   */

  }

  // Stable order tests

  // Note: Stable order means that the ordering doesn't change between iterations and versions.
  // Ideally, the ordering in test should never be updated.
  @Test
  public void stableIncidentEdgeOrder_edges_returnsInStableOrder() {
    assume().that(graph.incidentEdgeOrder().type()).isEqualTo(ElementOrder.Type.STABLE);

    populateTShapedGraph();

  }

  // Stable order tests

  // Note: Stable order means that the ordering doesn't change between iterations and versions.
  // Ideally, the ordering in test should never be updated.
  @Test
  public void stableIncidentEdgeOrder_edges_returnsInStableOrder() {
    assume().that(graph.incidentEdgeOrder().type()).isEqualTo(ElementOrder.Type.STABLE);

    populateTShapedGraph();

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  strategy: {}
  template:
    metadata:
      annotations:
        prometheus.io/path: /stats/prometheus
        prometheus.io/port: "15020"
        prometheus.io/scrape: "true"

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  strategy: {}
  template:
    metadata:
      annotations:
        prometheus.io/path: /stats/prometheus
        prometheus.io/port: "15020"
        prometheus.io/scrape: "true"

 *
 * <p>It is possible to configure a {@code RateLimiter} to have a warmup period during which time
 * the permits issued each second steadily increases until it hits the stable rate.
 *
 * <p>As an example, imagine that we have a list of tasks to execute, but we don't want to submit
 * more than 2 per second:
 *
 * <pre>{@code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "fake.docker.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http

spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  template:
    metadata:
      annotations:
        proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello