# specific language governing permissions and limitations
# under the License.

name: PR Automation
on:
  pull_request_target:
    types:
      - closed

jobs:
  pr-automation:
    name: PR Automation

concurrency:
  # On master/release, we don't want any jobs cancelled so the sha is used to name the group
  group: ${{ (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/release' ) && format('contributor-pr-base-{0}', github.sha) || format('contributor-pr-{0}', github.ref) }}
  cancel-in-progress: false

env:
  # Set the DEVELOCITY_ACCESS_KEY so that a Build Scan is generated
  DEVELOCITY_ACCESS_KEY: ${{ secrets.DEVELOCITY_ACCESS_KEY }}

          close-issue-reason: not_planned

          # PULL REQUESTS -----------------------------------------------------
          days-before-pr-stale: 30
          exempt-pr-labels: "from:contributor"
          stale-pr-label: stale
          stale-pr-message: >
            This pull request has been automatically marked as stale because it has not had recent activity.

# 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: |

name: 'Auto Assign PR to Author'
on:
  pull_request:
    types: [opened]

permissions: {}

jobs:
  add-reviews:
    permissions:
      contents: read  # for kentaro-m/auto-assign-action to fetch config file
      pull-requests: write  # for kentaro-m/auto-assign-action to assign PR reviewers
    runs-on: ubuntu-latest
    steps:

* Before the PR is applied, the new tests should fail.
* After applying the PR, the new tests should pass.
* Coverage should stay at 100%.
* If you see the PR makes sense, or we discussed it and considered it should be accepted, you can add commits on top of the PR to tweak it, to add docs, tests, format, refactor, remove extra files, etc.
* Feel free to comment in the PR to ask for more information, to suggest changes, etc.

### 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

* 👥 Update FastAPI People - Experts. PR [#13963](https://github.com/fastapi/fastapi/pull/13963) by [@tiangolo](https://github.com/tiangolo).
* ⬆ Bump ruff from 0.11.2 to 0.12.7. PR [#13957](https://github.com/fastapi/fastapi/pull/13957) by [@dependabot[bot]](https://github.com/apps/dependabot).

-->

#### What this PR does / why we need it:

#### Which issue(s) this PR is related to:
<!--
Please link relevant issues to help with tracking.

To automatically close the linked issue(s) when this PR is merged,
add the word "Fixes" before the issue number or link.
Do not use "Fixes" if the PR is of kind `failing-test` or `flake`.

Reference KEPs when applicable in addition to specific issues.

Examples:

        If you found a clear typo, please open a PR with a fix instead of opening an issue.

  - type: dropdown
    id: issue-type
    attributes:
      label: Issue type
      options:
        - Wrong or misleading information
        - Missing information
        - Styling or Accessibility
        - Typo (please open a PR instead)
    validations:
      required: true
  - type: textarea