# limitations under the License.
# ==============================================================================

name: Creates a GitHub Issue when a PR Rolled back via Commit to Master
on:
  push:
    branches:
      - master
      
permissions: {}

jobs:
  create-issue-on-pr-rollback:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
      pull-requests: read
    if: |

If you open a GitHub Issue, here is our policy:

1.  It must be a bug/performance issue or a feature request or a build issue or
    a documentation issue (for small doc fixes please send a PR instead).
1.  Make sure the Issue Template is filled out.
1.  The issue should be related to the repo it is created in.

**Here's why we have this policy:** We want to focus on the work that benefits
the whole community, e.g., fixing bugs and adding features. Individual support

# Change the value of CACHEBUSTER when upgrading the toolchain, or when testing
# different compilation methods. E.g. for a PR to test a new CUDA version, set
# the CACHEBUSTER to the PR number.
build --action_env=CACHEBUSTER=20220325

# Use Python 3.X as installed in container image
build --action_env PYTHON_BIN_PATH="/usr/local/bin/python3"

    # 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

### 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
  sufficient description, if applicable unit tests are added, if it is a

            Please reopen if you'd like to work on this further.
          days-before-pr-stale: 14
          days-before-pr-close: 14
          stale-pr-message: "This PR is stale because it has been open for 14 days with no activity. It will be closed if no further activity occurs. Thank you."

    This allows us to reduce the delay to external partners
    Add Labels - kokoro:force-run
    The PR is also assigned to specific teams to fast track review
    Additional reviewers can be added manually based on PR contents
  @param {!object}
    github enables querying for PR and also create issue using rest endpoint
    context has the commit message details in the payload

# ==============================================================================

name: Trusted Partner PR
on:
  pull_request_target:

permissions:
  contents: read

jobs:
  assign-partner-tags:
    runs-on: ubuntu-latest
    permissions:
      # Needed to attach tags into the PR
      issues: write
      contents: write
      pull-requests: write
    if: |

  console.log(`Original PR: ${pr_number} and Rollback Commit: ${rollback_commit}`);
  // Get the Original PR Details
  const pr_resp = await github.rest.pulls.get({
    owner,
    repo,
    pull_number: pr_number
  });
  if (pr_resp.status != 200 || pr_resp.data.state != 'closed') {
    console.log(`PR:{pr_number} is not found or closed.  Not a valid condition to create an issue.`);
    console.log(pr_resp);

-   Nightly jobs (Run nightly on the `nightly` branch)
    -   Uses `wheel.sh`, `libtensorflow.sh`, `code_check_full.sh`
-   Continuous jobs (Run on every GitHub commit)
    -   Uses `pycpp.sh`
-   Presubmit jobs (Run on every GitHub PR)
    -   Uses `pycpp.sh`, `code_check_changed_files.sh`

These "env" files match up with an environment matrix that roughly covers:

-   Different Python versions