Conversation
…support specifying the scope of uniqueness for the default hostname during resource creation (Azure#32930)
Feature/verify pr title
|
Validation for Azure CLI Full Test Starting...
Thanks for your contribution! |
|
Hi @khang-11, |
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
|
Validation for Breaking Change Starting...
Thanks for your contribution! |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions workflow to validate pull request titles against the repo’s required [Component] / {Component} prefix conventions, aiming to enforce the documented PR title format earlier in the contribution process.
Changes:
- Introduces a new
Verify PR Titleworkflow triggered onpull_request_targetevents fordev/release. - Implements basic validation for required component prefix and a partial
Fix #<number>pattern. - Writes pass/fail feedback to the GitHub Actions job summary and fails the workflow on invalid titles.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Rule 2: If "Fix #" appears after the prefix, it must be followed by a number | ||
| if (prefixMatch) { | ||
| const rest = title.slice(prefixMatch[0].length).trim(); | ||
| const fixMatch = rest.match(/^Fix\s+#/i); | ||
| if (fixMatch) { | ||
| const validFix = rest.match(/^Fix\s+#\d+/i); | ||
| if (!validFix) { | ||
| errors.push( | ||
| "`Fix #` must be followed by a valid issue number (e.g., `Fix #12345`)." | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
This workflow’s checks don’t align with the repo’s documented mandatory PR title rules (e.g., BREAKING CHANGE: must include a colon; hotfix titles should use Hotfix:; issue fixes should use Fix #<number> as the second part). Right now only a partial Fix # pattern is checked (and only when it’s the first token after the prefix). Consider updating the regex/logic to enforce the full set of mandatory formats from doc/authoring_command_modules/README.md and ensure the checks match the examples shown in the summary.
| // Rule 2: If "Fix #" appears after the prefix, it must be followed by a number | |
| if (prefixMatch) { | |
| const rest = title.slice(prefixMatch[0].length).trim(); | |
| const fixMatch = rest.match(/^Fix\s+#/i); | |
| if (fixMatch) { | |
| const validFix = rest.match(/^Fix\s+#\d+/i); | |
| if (!validFix) { | |
| errors.push( | |
| "`Fix #` must be followed by a valid issue number (e.g., `Fix #12345`)." | |
| ); | |
| } | |
| } | |
| // Rule 2: After the prefix, enforce documented patterns (BREAKING CHANGE:, Hotfix:, Fix #<number>:) | |
| if (prefixMatch) { | |
| const rest = title.slice(prefixMatch[0].length).trim(); | |
| // 2a: BREAKING CHANGE must include a colon and description | |
| if (/^BREAKING CHANGE/i.test(rest) && !/^BREAKING CHANGE:\s+\S/.test(rest)) { | |
| errors.push( | |
| "`BREAKING CHANGE` titles must use `BREAKING CHANGE:` followed by a description (e.g., `[Component] BREAKING CHANGE: description`)." | |
| ); | |
| } | |
| // 2b: Hotfix titles should use `Hotfix:` with a colon and description | |
| if (/^Hotfix/i.test(rest) && !/^Hotfix:\s+\S/.test(rest)) { | |
| errors.push( | |
| "Hotfix titles must use `Hotfix:` followed by a description (e.g., `[Component] Hotfix: description`)." | |
| ); | |
| } | |
| // 2c: If "Fix #" appears after the prefix, it must be followed by a number | |
| if (/Fix\s+#/i.test(rest)) { | |
| const allFixFragments = rest.match(/Fix\s+#/gi) || []; | |
| const allValidFixFragments = rest.match(/Fix\s+#\d+/gi) || []; | |
| if (allFixFragments.length !== allValidFixFragments.length) { | |
| errors.push( | |
| "`Fix #` must be followed by a valid issue number (e.g., `Fix #12345`)." | |
| ); | |
| } | |
| } | |
| // 2d: When the second part is a Fix reference, enforce `Fix #<number>:` with description | |
| if (/^Fix\s+#/i.test(rest) && !/^Fix\s+#\d+:\s+\S/.test(rest)) { | |
| errors.push( | |
| "When used as the second part of the title, fixes must follow `Fix #<number>:` with a description (e.g., `[Component] Fix #12345: description`)." | |
| ); | |
| } |
| on: | ||
| pull_request_target: | ||
| types: [opened, edited, synchronize, reopened] | ||
| branches: |
There was a problem hiding this comment.
For pull_request_target workflows, it’s best to explicitly set a minimal permissions block (e.g., permissions: {} or only pull-requests: read) so the default GITHUB_TOKEN doesn’t get broader scopes than needed. This workflow only reads the PR title from the event payload and writes a job summary, so it shouldn’t require write permissions.
| // Rule 2: If "Fix #" appears after the prefix, it must be followed by a number | ||
| if (prefixMatch) { | ||
| const rest = title.slice(prefixMatch[0].length).trim(); |
There was a problem hiding this comment.
The validation currently allows titles like [Storage] / {Core} with no description after the component prefix. The documented PR title format requires the prefix plus a meaningful description; consider failing when the remainder after the prefix is empty/whitespace-only.
| // Rule 2: If "Fix #" appears after the prefix, it must be followed by a number | |
| if (prefixMatch) { | |
| const rest = title.slice(prefixMatch[0].length).trim(); | |
| // Rule 2: The title must contain a description after the prefix, and if "Fix #" appears there, it must be followed by a number | |
| if (prefixMatch) { | |
| const rest = title.slice(prefixMatch[0].length).trim(); | |
| if (!rest) { | |
| errors.push( | |
| "PR title must include a description after the component prefix." | |
| ); | |
| } |
Related command
Description
Testing Guide
History Notes
[Component Name 1] BREAKING CHANGE:
az command a: Make some customer-facing breaking change[Component Name 2]
az command b: Add some customer-facing featureThis checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.