diff --git a/.github/policies/resourceManagement.yml b/.github/policies/resourceManagement.yml new file mode 100644 index 00000000000..1f5b53e10c0 --- /dev/null +++ b/.github/policies/resourceManagement.yml @@ -0,0 +1,163 @@ +# ============================================================================= +# Resource Management policy (GitHub "Policy Service" / GitOps). +# +# This file is consumed by Microsoft's GitOps Policy Service, NOT by GitHub +# Actions. The service watches the repo and reconciles behavior against the +# rules below. +# +# IMPORTANT SCOPING FACTS: +# * The service reads .github/policies/* ONLY from the repository's DEFAULT +# branch (currently `4.0`) and then applies the rules to PRs/issues +# targeting ANY branch. You therefore cannot keep "3.0 rules" on the 3.0 +# branch and "4.0 rules" on 4.0 -- everything lives here, on the default +# branch, and is discriminated by CONDITIONS (e.g. `targetsBranch`). +# * There is NO file- or group-level branch scope. Filenames are purely +# organizational. To scope a SET of rules to a branch, put a single +# `targetsBranch` guard in a parent task's top-level `if:` and nest the +# rules under its `then:` -- the top-level `if:` is ANDed, so every nested +# child inherits the guard (see the classic 3.0 group below). +# * The repo layout differs by era and uses DISJOINT top-level paths, so the +# area-label groups never collide: +# - classic (3.0/3.0-dev): SPECS*/, toolkit/ +# - azldev (4.0): base/, specs/, distro/, locks/, external/, ... +# +# Within a task, `if:` is a list of ANDed conditions and `then:` is a list of +# actions; both can be nested arbitrarily. +# ============================================================================= + +# Top-level scalars below are part of the primitive's template and intentionally +# left empty. `id` is managed by the Policy Service; `owner`/`where`/`onFailure`/ +# `onSuccess` are optional and unused. (`where:` selects which REPOS an +# org-distributed policy targets -- it is NOT a branch/PR filter.) +id: +name: GitOps.PullRequestIssueManagement +description: GitOps.PullRequestIssueManagement primitive +owner: +resource: repository +disabled: false +where: +onFailure: +onSuccess: +configuration: + resourceManagementConfiguration: + scheduledSearches: [] + eventResponderTasks: + # ======================================================================= + # GROUP: 4.0+ area labels (GATED to the 4.0 branch). + # The single `or(targetsBranch ...)` guard scopes the ENTIRE group; every + # nested `if/then` inherits it. + # ======================================================================= + - description: Area labels for PRs that target 4.0 + if: + - payloadType: Pull_Request + - or: + - targetsBranch: + branch: "4.0" + then: + # Component definitions, rendered specs, and lock files -> Packaging. + - if: + - filesMatchPattern: + pattern: "^(base/comps|specs|locks)/" + matchAny: true # true = label if ANY changed file matches + then: + - addLabel: + label: Packaging + # Documentation + - if: + - filesMatchPattern: + pattern: "^docs/" + matchAny: true + then: + - addLabel: + label: documentation + # Branch-name label. The group is already gated to 4.0, so every PR + # reaching here targets 4.0 -- no nested condition needed. + - addLabel: + label: "4.0" + + # ======================================================================= + # GROUP: 3.0-era area labels (GATED to the 3.0 branches). + # The single `or(targetsBranch ...)` guard in this parent `if:` scopes the + # ENTIRE group; every nested `if/then` below inherits it. To stop labeling + # a retired branch, just remove its line from the `or:` list. + # ======================================================================= + - description: Area labels for the classic (SPECS/toolkit) layout, 3.0 only + if: + - payloadType: Pull_Request + - or: + - targetsBranch: + branch: "3.0" + - targetsBranch: + branch: "3.0-dev" + - targetsBranch: + branch: "fasttrack/3.0" + then: + - if: + - filesMatchPattern: + pattern: "^(SPECS|SPECS-EXTENDED|SPECS-SIGNED)/" + matchAny: true + then: + - addLabel: + label: Packaging + - if: + - filesMatchPattern: + pattern: "^SPECS-EXTENDED/" + matchAny: true + then: + - addLabel: + label: specs-extended + - if: + - filesMatchPattern: + pattern: "^toolkit/docs/" + matchAny: true + then: + - addLabel: + label: documentation + - if: + - filesMatchPattern: + pattern: "^toolkit/(tools|scripts)/" + matchAny: true + then: + - addLabel: + label: Tools + - if: + - filesMatchPattern: + pattern: "^toolkit/(imageconfigs|tools/imagegen/configuration)/" + matchAny: true + then: + - addLabel: + label: Schema + + # Branch-name labels. We always add the '3.0' label for any PR targeting a + # 3.0 branch, and *also* add a "fasttrack/3.0" label for PRs targeting the + # fasttrack branch. + - addLabel: + label: "3.0" + - if: + - targetsBranch: + branch: "fasttrack/3.0" + then: + - addLabel: + label: "fasttrack/3.0" + + # ======================================================================= + # Era-independent: label PRs opened by an automation bot account. + # `issueAuthor: false` -> match when the BOT is the activity sender. + # The `or:` block matches when EITHER known automation account opened the + # PR; add more accounts here as they appear. + # ======================================================================= + - description: Label automated PRs opened by a bot account + if: + - payloadType: Pull_Request + - isAction: + action: Opened + - or: + - isActivitySender: + user: CBL-Mariner-Bot + issueAuthor: false + - isActivitySender: + user: azurelinux-security + issueAuthor: false + then: + - addLabel: + label: Automatic PR