Add investigation & debugging practices to copilot-instructions#11141
Add investigation & debugging practices to copilot-instructions#11141jonathanpeppers merged 3 commits intomainfrom
Conversation
Capture five high-leverage lessons learned while debugging the CoreCLRTrimmable lane failures: 1. Reproduce CI failures locally — don't iterate through CI 2. Nuke bin/ and obj/ when the build enters a weird state 3. Verify code paths with logging before reasoning about them 4. Decompile the generated .dll when generated code misbehaves 5. 'am instrument' going silent means it crashed, not hung These rules are placed in .github/copilot-instructions.md so every future agent loads them automatically. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds an “Investigation & Debugging Practices” section to .github/copilot-instructions.md to capture concrete, high-leverage debugging habits for dotnet/android’s cross-layer stack (managed ↔ JNI ↔ native ↔ generated code), motivated by lessons from the CoreCLRTrimmable CI investigation.
Changes:
- Document a local repro command pattern for device-test CI failures.
- Add guidance on cleaning build artifacts, validating call paths via logging, and decompiling generated assemblies.
- Document how to interpret silent
am instrumentruns as crashes and where to look for evidence.
jonathanpeppers
left a comment
There was a problem hiding this comment.
🤖 AI Review Summary
Verdict:
Found 3 issues: 1 warning, 2 suggestions.
Great initiative capturing hard-won lessons from the CoreCLRTrimmable investigation (#11091). The content is valuable — these are real failure modes that cost hours.
⚠️ Documentation: "nuke bin/obj" duplicates the existing Troubleshooting section (copilot-instructions.md:225)- 💡 Documentation: Code block uses bash-only commands; no Windows equivalents (
copilot-instructions.md:208) - 💡 Documentation: Some bullets are verbose — consider tightening for token budget (
copilot-instructions.md:218)
CI note: The internal Xamarin.Android-PR check is failing, but this appears unrelated to a docs-only change and may need a re-run.
👍 The "absence of log output is itself evidence" insight is genuinely useful and well-articulated.
Review generated by android-reviewer from review guidelines.
…date bin/obj guidance - Add Windows note for make/dotnet-local.sh commands - Cross-reference Troubleshooting section instead of duplicating bin/obj cleanup - Tighten verbose bullets to reduce token cost - Expand Troubleshooting Build entry with full make command Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…lues, use Android.Util.Log - Replace invalid 'legacy' with correct values: llvm-ir|managed|trimmable - Use Android.Util.Log (general C#) instead of AndroidLog.Print (NativeAOT-internal) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Description
Adds an "Investigation & Debugging Practices" section to
.github/copilot-instructions.mdcapturing five high-leverage lessons from the CoreCLRTrimmable CI lane investigation (#11091):make+dotnet-local.shinvocation for device tests.bin/andobj/when the build enters a weird state. Stale incremental output causes phantom errors..dllwhen generated code misbehaves. Don't trust generator source to tell you what it emitted.am instrumentgoing silent means it crashed, not hung. Checklogcatfor the fatal signal.These rules target failure modes that cost significant time during PR #11091 — each one would have caught a real dead-end before hours were spent on it.
Split out from #11091 to keep the tests/CI PR focused.
Follow-up issues filed during the same retrospective
am instrumentcrashes