Skip to main content

fix-random-ci-test-failure

Investigate and fix flaky/random CI test failures in dotnet/macios. Trigger on GitHub issues describing intermittent test failures, CI postmortem issues, or when asked to fix a flaky test. Analyzes test code, identifies root causes (shared state, environment dependencies, race conditions), and applies fixes.

ソース情報

リポジトリ
dotnet/macios
ソースの最終更新活動
2026年4月30日 15:21
検出された SKILL.md の言語
英語
スター
2,912
フォーク
579

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
fix-random-ci-test-failure
description
Investigate and fix flaky/random CI test failures in dotnet/macios. Trigger on GitHub issues describing intermittent test failures, CI postmortem issues, or when asked to fix a flaky test. Analyzes test code, identifies root causes (shared state, environment dependencies, race conditions), and applies fixes.
# Fix Random CI Test Failure Investigate and fix flaky CI test failures reported in GitHub issues for dotnet/macios. ## When to Use - User shares a GitHub issue about a flaky/intermittent test failure - Issue has the `ci-postmortem` label - User asks to fix a randomly failing test - Test failures appear across unrelated PRs (indicating environment-dependent flakiness) ## Workflow ### 1. Gather Failure Context Read the GitHub issue to extract: - **Test name** and **test suite** (e.g., monotouch-test) - **Error message** and **assertion failure details** - **Platform** (iOS, macOS, tvOS, Mac Catalyst) - **Affected builds** — check if failures span unrelated PRs (confirms flakiness vs. regression) If build URLs are provided, inspect logs for additional context (stack traces, timing info). ### 2. Locate and Analyze the Test Find the test source file: ``` grep -r "TestMethodName" tests/ ``` Read the **full test method** and all helper methods it calls. Understand: - What external resources does it use? (keychain, file system, network, simulators) - Does it use shared/hardcoded identifiers that could collide across parallel runs? - Does it properly clean up before and after execution? - Are there error paths that silently swallow failures? ### 3. Identify Root Cause Category Common flaky test root causes in this repo: #### Shared State / Resource Conflicts - **Symptom**: Test uses hardcoded identifiers (e.g., fixed keychain entries, file paths, port numbers) - **Fix**: Use process-unique identifiers (PID, GUID, bundle ID + test name) - **Reference**: `tests/monotouch-test/Security/KeyChainTest.cs` uses per-process unique IDs #### Environment-Dependent State - **Symptom**: Test depends on OS-level state (keychain, permissions, network availability) - **Fix**: Add robust setup/teardown, handle unexpected initial states, add retry logic for transient errors #### Unhandled Error Codes - **Symptom**: Code only handles expected success/failure codes, silently fails on unexpected ones - **Fix**: Add fallback handling for unexpected status codes, log diagnostic info #### Race Conditions / Timing - **Symptom**: Test passes locally but fails intermittently in CI - **Fix**: Add proper synchronization, increase timeouts, avoid timing-dependent assertions #### LAContext / Authentication Issues (Security tests) - **Symptom**: `InvalidRecord` or authentication-related errors on keychain operations - **Fix**: Only attach `LAContext` where actually needed (not on plain query/delete operations) ### 4. Apply the Fix When fixing: 1. **Prefer unique identifiers over shared ones.** Use `Process.GetCurrentProcess ().Id`, `Guid.NewGuid ()`, or `{bundleId}-{testType}-{pid}` patterns for resource identifiers. 2. **Create minimal query records.** For search/delete operations, don't attach unnecessary attributes (like `LAContext`) that can cause intermittent errors. 3. **Handle all status codes.** Never silently return `false` for unexpected error codes. Either handle them with a fallback path or fail with a descriptive assertion message. 4. **Add diagnostic logging.** Use `TestContext.Out.WriteLine` to log operation results that would help diagnose future failures. 5. **Clean up legacy state.** If renaming identifiers, also clean up entries from old names that may linger on CI agents. 6. **Always clean up in `finally` blocks.** Ensure test resources are released even on failure. ### 5. If the Fix is Unclear If you cannot determine the root cause with available information: 1. **Add diagnostic logging** to capture operation results (status codes, error details) in future failures. 2. **Log the initial state** at test start (e.g., does the resource already exist before the test runs?). 3. **Include all relevant status codes** in assertion failure messages. 4. Explain to the user what additional information the logging will provide and what hypotheses it will help test. ### 6. Create the PR - Branch naming: `dev/{username}/fix-{test-name}` or similar - Commit message should explain all root causes addressed - Reference the GitHub issue with `Fixes #NNNN` if the change actually fixes the problem, or `Ref #NNNN` if it only adds logging/diagnostics - Add the `copilot` label to the PR ## Key Patterns in This Repo - Keychain tests in `tests/monotouch-test/Security/` are particularly prone to flakiness due to shared macOS keychain state on CI agents - `InitSecRecord` in `RecordTest.cs` attaches `LAContext` to all `SecRecord` instances — this is sometimes unnecessary and can cause `InvalidRecord` errors - `KeyChainTest.cs` demonstrates the recommended pattern: per-process unique identifiers using bundle ID + test type + PID - Tests run on shared CI agent machines where leftover state from previous runs can cause interference
GitHubで見る