GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"

  # https://github.com/marketplace/actions/alls-green#why
  test-redistribute-alls-green:  # This job does nothing and is only used for the branch protection
    if: always()
    needs:
      - test-redistribute
    runs-on: ubuntu-latest
    steps:
      - name: Decide whether the needed jobs succeeded or failed
        uses: re-actors/alls-green@release/v1

# Note that here we want the latest version that matches TF major.minor version
# Note that we must use nightly here as these are used in nightly jobs
# For release jobs, we will pin these on the release branch
keras-nightly ~= 3.12.0.dev
tb-nightly ~= 2.20.0.a
# For new protobuf, if V.x.y is gencode version, then runtime version U must be
# V <= U <= V+1
# More info at https://protobuf.dev/support/cross-version-runtime-guarantee/

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package promotion

abstract class PublishGradleDistributionFullBuild(
    // The branch to be promoted
    promotedBranch: String,
    prepTask: String? = null,
    promoteTask: String,
    triggerName: String,
    gitUserName: String = "bot-teamcity",
    gitUserEmail: String = "******@****.***",

==== BWC Testing against a specific remote/branch

Sometimes a backward compatibility change spans two versions. A common case is a new functionality
that needs a BWC bridge in an unreleased versioned of a release branch (for example, 5.x).
To test the changes, you can instruct Gradle to build the BWC version from a another remote/branch combination instead of

      # Ref: https://github.com/actions/checkout/issues/2313
      - uses: actions/checkout@v5
        with:
          # To allow latest-changes to commit to the main branch
          token: ${{ secrets.FASTAPI_LATEST_CHANGES }}
      # Allow debugging with tmate
      - name: Setup tmate session
        uses: mxschmitt/action-tmate@v3

1.  API changes require discussion, use cases, etc. Code comes later.
2.  Pull requests are great for small fixes for bugs, documentation, etc.
3.  Pull requests are not merged directly into the master branch.
4.  Code contributions require signing a Google CLA.

API changes
-----------

We make changes to Guava's public [APIs][], including adding new APIs, very

   * I/O resource, it should generally be safe in the case of a resource that's being used only for
   * reading, such as an {@code InputStream}. Unlike with writable resources, there's no chance that
   * a failure that occurs when closing the stream indicates a meaningful problem such as a failure
   * to flush all bytes to the underlying resource.
   *

    init {
        id("Promotion_StartReleaseCycle")
        name = "Start Release Cycle"
        description = "Promotes a successful build on master as the start of a new release cycle on the release branch"

        params {
            text(
                "gitUserEmail",
                "",
                label = "Git user.email Configuration",

 * when the ResolutionListener interface deprecation of the manageArtifact
 * method (and the [yet to be done] addition of these methods to that
 * interface) has had a chance to propagate to all interested plugins.
 */
@Deprecated
public interface ResolutionListenerForDepMgmt {
    void manageArtifactVersion(Artifact artifact, Artifact replacement);

    outputs:
      src: ${{ steps.filter.outputs.src }}
    steps:
    - uses: actions/checkout@v6
    # For pull requests it's not necessary to checkout the code but for the main branch it is
    - uses: dorny/paths-filter@v4
      id: filter
      with:
        filters: |
          src:
            - .github/workflows/test.yml
            - docs_src/**
            - fastapi/**