// We want it to be triggered only when there're pending changes in the specific vcs root, i.e. GradleMaster/GradleRelease
                    triggerRules = "+:root=${VersionedSettingsBranch.fromDslContext().vcsRootId()}:."
                    // The promotion itself will be triggered on gradle-promote's master branch

                    // We want it to be triggered only when there're pending changes in the specific vcs root, i.e. GradleMaster/GradleRelease
                    triggerRules = "+:root=${VersionedSettingsBranch.fromDslContext().vcsRootId()}:."
                    // The promotion itself will be triggered on gradle-promote's master branch

    /**
     * Whether the <a href="https://www.jetbrains.com/help/teamcity/configuring-vcs-triggers.html">VCS trigger</a>
     * should be enabled, i.e. when new commits are pushed to this branch, should a ReadyForNightly job
     * be triggered automatically?
     *
     * Currently, we only enable VCS trigger for `master`/`release`/`releaseNx` branches.
     */

  include(":okhttp-android")
  include(":android-test")
  include(":android-test-app")
}

enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")

/**
 * Avoid a crash in IntelliJ triggered by Android submodules.
 *
 * ```
 * java.lang.AssertionError: Can't find built-in class kotlin.Cloneable
 *   at org.jetbrains.kotlin.builtins.KotlinBuiltIns.getBuiltInClassByFqName(KotlinBuiltIns.java:217)

  ) {
    val body = response.body.string()
    responses.add(RecordedResponse(call.request(), response, null, body, null))
    (this as Object).notifyAll()
  }

  /**
   * Returns the recorded response triggered by `request`. Throws if the response isn't
   * enqueued before the timeout.
   */
  @Synchronized
  fun await(url: HttpUrl): RecordedResponse {

      uses: actions/checkout@v2
      with:
        # We must fetch at least the immediate parents so that if this is
        # a pull request then we can checkout the head.
        fetch-depth: 2

    # If this run was triggered by a pull request event, then checkout
    # the head of the pull request instead of the merge commit.
    - run: git checkout HEAD^2
      if: ${{ github.event_name == 'pull_request' }}

	ConfigurationID string `json:"configurationId"`
	Bucket          Bucket `json:"bucket"`
	Object          Object `json:"object"`
}

// Source represents client information who triggered the event.
type Source struct {
	Host      string `json:"host"`
	Port      string `json:"port"`
	UserAgent string `json:"userAgent"`
}

// Event represents event notification information defined in

/// tip

Note that we're using async/await with the new `AsyncClient` - the request is asynchronous.

///

/// warning

If your application relies on lifespan events, the `AsyncClient` won't trigger these events. To ensure they are triggered, use `LifespanManager` from <a href="https://github.com/florimondmanca/asgi-lifespan#usage" class="external-link" target="_blank">florimondmanca/asgi-lifespan</a>.

///

## Other Asynchronous Function Calls

Additionally, we MUST accept incoming traffic during this time, both new and existing.
Typically, it is rare to get new connections after shutdown has started - once shutdown is triggered the endpoint is marked `NotReady` and removed from load balancing consideration.
However, some applications do not utilize Service readiness (connecting directly to the pod, etc).

A push occurs when Istiod detects an update of some set of configuration is needed. This results in roughly the same result as a Request (new configuration is pushed to the client), and is just triggered by a different source.

Various components described in Config Ingestion can trigger a Config Update. These are batched up ("debounced"), to avoid excessive activity when many changes happen in succession, and eventually enqueued in the Push Queue.