.DEFAULT_GOAL := default

# This repository has been enabled for BUILD_WITH_CONTAINER=1. Some
# test cases fail within Docker, and Mac + Docker isn't quite perfect.
# For more information see: https://github.com/istio/istio/pull/19322/

BUILD_WITH_CONTAINER ?= 1
CONTAINER_OPTIONS = --mount type=bind,source=/tmp,destination=/tmp --net=host

export COMMONFILES_POSTPROCESS = tools/commonfiles-postprocess.sh

ifeq ($(BUILD_WITH_CONTAINER),1)

# under the License.

name: Can Maven build itself

on: [push, pull_request]

# clear all permissions for GITHUB_TOKEN
permissions: {}

jobs:
  build:

    # execute on any push or pull request from forked repo
    if: github.event_name == 'push' || ( github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork )

    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]

# Build for both JAX and TF usage.  We do these in one place because they share
# almost all of the same cache layers
export DOCKER_BUILDKIT=1
for target in jax tf; do
  AR_IMAGE="$AR_IMAGE_PATH:$target-$TAG"
  docker pull "$AR_IMAGE" || true
  # Due to some flakiness of resources pulled in the build, allow the docker
  # command to reattempt build a few times in the case of failure (b/302558736)
  set +e
  for i in $(seq 1 5)
  do

   * with {@code FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6409434">Sun bug 6409434</a> is fixed.
   * It's unclear whether nulls were to be permitted or forbidden, but presumably the eventual fix
   * will be to permit them, as it seems more likely that code would depend on that behavior than on

       * we're copying into a `contents` array whose type allows it to contain nulls. Still, it's
       * worth noting that we promise not to put nulls into the array in the first `size` elements.
       * We uphold that promise here because our callers promise that `elements` will not contain
       * nulls in its first `n` elements.
       */
      System.arraycopy(elements, 0, contents, size, n);
      size += n;

name: Deploy Docs
on:
  workflow_run:
    workflows:
      - Build Docs
    types:
      - completed

permissions:
  deployments: write
  issues: write
  pull-requests: write
  statuses: write

env:
  UV_SYSTEM_PYTHON: 1

jobs:
  deploy-docs:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}

    # Only shows Added, Changed, Modified, Renamed, and Type-changed files
    if [[ "$(git rev-parse --abbrev-ref HEAD)" = "pull_branch" ]]; then
        # TF's CI runs 'git fetch origin "pull/PR#/merge:pull_branch"'
        # To get the as-merged branch during the CI tests
        git diff --diff-filter ACMRT --name-only pull_branch^ pull_branch > $BATS_FILE_TMPDIR/changed_files
    else

        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - name: Build binary and run python tests
        shell: bash
        run: |
          CI_DOCKER_BUILD_EXTRA_PARAMS="--pull --build-arg py_major_minor_version=${{ matrix.pyver }} --build-arg is_nightly=1 --build-arg tf_project_name=tf_nightly_ci" \

                            // Note: using DOM instead of use of
                            // org.apache.maven.plugin.descriptor.PluginDescriptor
                            // as it would pull in dependency on:
                            // - maven-plugin-api (for model)
                            // - Plexus Container (for model supporting classes and exceptions)

 * When merging `releaseX` branch into `master`, we should only use the release note from the `master` branch,
 * but sometimes changes on release notes.md was brought to master and merged unnoticed,
 * e.g https://github.com/gradle/gradle/pull/25825
 *
 * This script is to check if there is any merge commit that brings changes from release branch to master.
 * Usage: groovy CheckBadMerge.groovy <commit1> <commit2> ...