Add GitHub Copilot instructions - #827
Conversation
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
Mike Harder (mikeharder)
left a comment
Mike Harder (mikeharder)
left a comment
There was a problem hiding this comment.
These auto-gen instructions look good enough to me as a starting point, future updates can be made manually, or by asking copilot to update its own instructions.
|
Copilot: disable formatting on agent instructions, by adding |
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds repository-specific GitHub Copilot guidance and updates formatting ignores so instruction files aren’t auto-formatted.
Changes:
- Added
.github/copilot-instructions.mddocumenting repo architecture, build/test commands, and key conventions. - Updated
.github/.prettierignoreto exclude*instructions.mdfiles from Prettier formatting.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/copilot-instructions.md | Introduces Copilot agent instructions for working effectively in this Rush monorepo. |
| .github/.prettierignore | Excludes instruction markdown files from Prettier formatting runs under .github/. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
Co-authored-by: mikeharder <9459391+mikeharder@users.noreply.github.com>
|
|
||
| ### Adding New Linter Rules | ||
| 1. Add rule to staging pipeline first (set to run only in staging) | ||
| 2. Wait for at least 10 PRs to verify no false positives |
There was a problem hiding this comment.
isnt this an iterative development? How will it know to analyze production PR's and move to prod?
Also, I dont think the stagingOnly has any significance now as there isnt a staging pipeline.
Instead we can ask it to add the label to trigger the staging-lint check pipeline. Wish it can also validate the errors generated.
| 5. For significant changes, manually update `changelog.md` | ||
|
|
||
| ### Adding New Linter Rules | ||
| 1. Add rule to staging pipeline first (set to run only in staging) |
There was a problem hiding this comment.
Copilot
There is no staging pipeline and hence the stagingOnly option doesnt really have any significance.
Instead update this to have the rule name added as a label which will trigger the staging-lint check pipeline.
Also, is there a way you can validate if the errors generated are accurate
There was a problem hiding this comment.
Updated the instructions to reflect the current workflow using test-<RuleName> labels to trigger the staging-lint check pipeline. Added a new section explaining how to test rules with the staging-lint check workflow, and clarified that stagingOnly is now legacy. (7f931c7)
Regarding validation of errors: The staging-lint check workflow generates a linter-findings.txt artifact that you can download to review the violations found. Manual review is currently needed to validate accuracy.
Co-authored-by: AkhilaIlla <36493984+AkhilaIlla@users.noreply.github.com>
| 1. Add the new rule with appropriate severity and documentation | ||
| 2. Add a label to your PR in the format `test-<RuleName>` to trigger the staging-lint check pipeline | ||
| 3. Verify the rule works correctly by checking the staging-lint check results | ||
| 4. Wait for at least 10 PRs in azure-rest-api-specs to validate no false positives |
There was a problem hiding this comment.
Copilot how are you planning to implement these 2 instructions
There was a problem hiding this comment.
These instructions are written for human developers, not for automated implementation. Steps 4-5 describe a validation and release process:
Step 4 (Wait for 10 PRs): This is a manual monitoring step where developers review staging-lint results across multiple PRs to ensure the rule doesn't produce false positives. This requires human judgment and cannot be automated.
Step 5 (Create release PR): This follows the release process in CONTRIBUTING.md, which involves running rush change, updating changelogs, and coordinating deployment. While I can help create the PR, the deployment coordination requires human oversight.
If you'd like to clarify that these are manual steps, I can update the wording to make it more explicit.
There was a problem hiding this comment.
There is no release PR process.
the author validates the rule using the staging lint check and then the rule is released.
Copilot update based on this context
There was a problem hiding this comment.
Updated the instructions to reflect the actual workflow. Removed references to waiting for 10 PRs and creating a separate release PR. The new steps show that after validation with the staging-lint check, the rule is automatically deployed when the PR is merged. (a25e910)
Co-authored-by: AkhilaIlla <36493984+AkhilaIlla@users.noreply.github.com>
|
Tejaswi Salaigari (@tejaswiMinnu): Can you please approve this? |
.github/copilot-instructions.mdwith comprehensive instructionsWorkspace.resolveRef(enhancedSchema, inventory)matching actual APIEnhancedSchema | undefined)test-<RuleName>labels for staging-lint checkstagingOnlyis legacy and staging-lint check is the current approach**/*instructions.mdto.github/.prettierignoreOriginal prompt
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.