Management Autopr Review

Management AutoPR Review Rules

Use only for Azure/azure-sdk-for-java PRs that are non-draft, target main, originate in the same repository, have a title containing [AutoPR azure-resourcemanager-, and are authored by azure-sdk, azure-sdk-automation[bot], or app/azure-sdk-automation.

The review is advisory. It does not approve, merge, modify code, access the spec repository, or replace other automated and human review.

Java-change gate

Never review a file whose normalized repository-relative path contains a generated segment ((^|/)generated(/|$)). This includes generated samples and tests.

Review opened, reopened, and ready_for_review only when the PR contains a changed .java file outside a generated path. On synchronize, review only when the pushed before..after range changes such a .java file. POM-only, CHANGELOG-only, metadata-only, generated-only, and refresh-only pushes produce no comment.

Once the Java gate passes, supporting POM, CHANGELOG, metadata, and CI files may be read as evidence, except files under a generated path.

Review rules

MGMT-RELEASE-PLAN: missing release-plan link

• Severity: Warning

Normalize casing and Markdown emphasis. Accept both plain Release Plan link: https://example.com/release-plan and formatted **Release plan link:** [text](https://example.com/release-plan). Require an HTTP(S) URL.

Report when the PR description contains no accepted release-plan link. Cite the PR description and continue the remaining review passes so other high-value concerns are not hidden.

MGMT-FOLDER: service-folder mismatch

• Severity: Blocking

For a newly added management module, split its directory name on -. The expected service identity is always the third segment:

azure-resourcemanager-<service-identity>[-<module-suffix>...]

Ignore the fourth and later segments when comparing the module with its sdk/<service>/ folder. For example, azure-resourcemanager-compute-bulkactions belongs in sdk/compute.

Report whenever the folder <service> differs from the module's third segment. Explain that the likely source is the service-dir configuration in the upstream tspconfig.yaml, without accessing that repository.

MGMT-VERSION: stable package on a preview API

• Severity: Blocking

Read all API versions from the current CHANGELOG entry. A multi-service entry may use Package api-version <service-group>: <version>, ...; use every value after : and do not treat the service-group names as versions. Fall back to apiVersions in the generated _metadata.json. When apiVersions is an object that maps service groups to versions, likewise use every object value. If any extracted version ends in -preview, the Java package version must contain a beta suffix. Report a stable package generated from any preview API, even when its other API versions are stable.

Do not infer preview status from feature names or dates.

MGMT-API-VERSION: generated API-version context

• Severity: Informational

Read the effective API-version set from the current CHANGELOG entry, falling back to apiVersions in the generated _metadata.json. For a CHANGELOG service-group: version list or an apiVersions object, report the distinct version values rather than the service-group names. Report the exact version or versions as review context.

Treat the API-version set as the informational item's state. If a later commit changes that set, emit MGMT-API-VERSION again as New with the new values, even when a prior workflow comment already contains this ID. This provides an additional guard for MGMT-API-VERSION-OVERLAP. Do not request corrective action.

MGMT-LRO: suspicious generated LRO response shape

• Severity: Warning

Report only when the PR newly adds a <ClientMethod>Response and a corresponding <ClientMethod>Headers model whose headers include location or retry-after. Identify the method and both generated types. Explain that the shape may indicate incorrect LRO modeling upstream.

Do not report ordinary response wrappers or headers models without those headers.

MGMT-LIST-RETURN: non-pageable list operation

• Severity: Warning

Review newly added user-facing public operations whose name starts with list. When the return type is neither PagedIterable<T> nor PagedFlux<T>, inspect the returned model. Report only when that model exposes a collection-valued value property. Identify the method, return type, and value element type, then ask whether the operation should expose the standard pageable shape.

Do not report listWithResponse methods, low-level protocol client methods, private single-page helpers, or pre-existing operations. A PagedIterable<T> or PagedFlux<T> return is valid. Treat a response model without a value property as a genuine non-pageable action response.

MGMT-MANAGER-NAME: suspicious management entry-point name

• Severity: Warning

Review a public top-level class ending in Manager only when the PR adds or renames it in the management package's root Java namespace. Report when any one of these independent signals is apparent:

• a compound service name has an apparent casing boundary error, such as ContainerserviceManager instead of ContainerServiceManager;
• the class name has an apparent spelling error, supported by the module name, root Java package, or other public symbols; or
• the class-name stem has no meaningful lexical overlap with either the Maven module name after azure-resourcemanager- or the root Java package identity.

For the lexical-overlap check, split CamelCase and hyphenated identities, compare case-insensitively, and allow a meaningful class token of at least four characters to occur within a combined package identity. Ignore generic tokens such as azure, resource, resources, manager, management, service, api, and client.

Do not enforce exact branding, abbreviations, singular versus plural, token order, or optional suffixes. For example, ContainerAppsApiManager is related to azure-resourcemanager-appcontainers. Do not report an oddly named entry-point that was already present on the base branch. Identify the class and package evidence, then ask whether the generated entry-point name is intended.

MGMT-API-VERSION-OVERLAP: overlapping API-version generations

• Severity: Blocking

Report when the branch contains package output from more than one API-version generation. Evidence includes either:

• multiple package API-version lines in one release section, or
• regeneration of a release section that was already dated before this PR.

The likely root cause is either an earlier generated package that has not been released or multiple generation runs targeting different API versions on the same branch. Use the CHANGELOG as evidence, not as the defect itself. Ask which API-version generation should remain and whether the earlier package should be released or removed. Ordinary dependency, POM, or release metadata changes are expected.

MGMT-BREAKING: generated public API break

• Severity: Warning

Use the current CHANGELOG release section as the primary and authoritative source. For a GA package version, its breaking-change section compares the release with the previous GA release and can identify a break that entered the main branch during an earlier beta.

Do not require the current Java diff to contain the break. Cite the CHANGELOG file and affected release entry. Optionally cite a non-generated Java file when it provides useful corroboration.

For a GA release, report one MGMT-BREAKING concern summarizing substantive breaking items listed in the current CHANGELOG section, including removed public types or methods, changed access, renamed APIs, and changed public signatures or return types. Request human confirmation that the GA breaks are intended.

Do not raise MGMT-BREAKING for a beta package version. Beta packages may break, and their CHANGELOG comparison may be against a prior beta. Additive items are not breaking.

MGMT-NEW-MODULE: new management module context

• Severity: Informational

Report when the PR adds a new sdk/<service>/azure-resourcemanager-<module>/pom.xml. Identify the service folder and module so human reviewers know the PR introduces a new module and may warrant broader attention. Do not imply a defect or request corrective action.

Verification and output

Use only these severity levels:

MGMT-FOLDER, MGMT-VERSION, and MGMT-API-VERSION-OVERLAP are Blocking. MGMT-RELEASE-PLAN, MGMT-LRO, MGMT-LIST-RETURN, MGMT-MANAGER-NAME, and MGMT-BREAKING are Warning. MGMT-API-VERSION and MGMT-NEW-MODULE are Informational.

Every item must cite a repository-relative file and affected symbol or release entry and state whether it is New, Carried forward, or Resolved. Blocking and Warning items request one concrete human action or verification. Informational items provide context without requesting action. MGMT-RELEASE-PLAN cites the PR description. Reuse stable IDs across commits, except that a changed MGMT-API-VERSION value is emitted again as New. When a new head SHA passes the Java gate, include each still-applicable prior item as Carried forward in the replacement current-state comment; do not restate its question as New.

Code-format the complete bracketed concern ID, including the square brackets, for example [MGMT-LIST-RETURN]. Do not wrap the complete finding in backticks, because evidence may contain its own inline code spans.

Output:

## Automated management AutoPR review

- Head SHA: `<sha>`
- Package: `<package>`
- Release type: `<stable|beta>`
- API version: `<version(s)>`
- CHANGELOG: `<release and date>`
- Java changes reviewed: `<summary>`
- Breaking changes: `<none|summary>`
- Decision: `<no high-confidence concerns|human attention requested>`

### Blocking

- `[MGMT-...]` New|Carried forward|Resolved — evidence and requested action

### Warning

- `[MGMT-...]` New|Carried forward|Resolved — evidence and verification request

### Informational

- `[MGMT-...]` New|Carried forward|Resolved — context

Order sections as Blocking, Warning, Informational and omit empty sections. Silence or noop is correct when no review state changes.