fix: exclude errored code scanning analyses from migration#1529
fix: exclude errored code scanning analyses from migration#1529lindluni wants to merge 6 commits intogithub:mainfrom
Conversation
Filter out code scanning analyses with non-empty error fields when listing analyses from the source repository, preventing failed analyses from being migrated to the target repository. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Brett Logan <lindluni@github.com>
Clarified the bug fix description for `migrate-code-scanning-alerts` to specify exclusion of analyses with processing errors on initial uploads.
There was a problem hiding this comment.
Pull request overview
This PR prevents migrate-code-scanning-alerts migrations from failing on code scanning analyses that have an error present in the List Analyses API response by filtering those analyses out before attempting SARIF retrieval.
Changes:
- Filter out code scanning analyses whose
errorfield is non-empty when listing analyses. - Add unit test coverage for excluding errored analyses.
- Add a release note entry describing the bug fix.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Octoshift/Services/GithubApi.cs | Filters out analyses with a non-empty error field before building CodeScanningAnalysis results. |
| src/OctoshiftCLI.Tests/Octoshift/Services/GithubApiTests.cs | Adds a test ensuring analyses with populated error are excluded from results. |
| RELEASENOTES.md | Documents the behavior change for migrate-code-scanning-alerts. |
Unit Test Results 1 files 1 suites 25s ⏱️ Results for commit 5e59796. ♻️ This comment has been updated with latest results. |
|
I don't love that the error looks like it's silently dropped. Is this error message reported anywhere? |
… them Move error handling from GithubApi (silent filter) to CodeScanningAlertService (log and skip). Errored analyses now emit a warning with their ID and error message before being skipped during migration. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Brett Logan <lindluni@github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Brett Logan <lindluni@github.com>
|
I updated the implementation. I was a bit overzealous on the logging. I'm trying to make it clear this was an error processing the original upload and not with the process GEI is undertaking. Trying to avoid users opening issues with support and migration-friction thinking they had errors in the tool. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Brett Logan <lindluni@github.com>
|
Filter out code scanning analyses with non-empty error fields when listing analyses from the source repository, preventing failed analyses from being migrated to the target repository.
When the
migrate-code-scanning-alertsis invoked, it used theListAnalysesAPI. The results objects in the returned array have anerrorfield. If on the initial upload the SARIF failed to process, the error field is populated. When we try toGetAnalysisto retrieve the SARIF content, we get a422 Unprocessable Entitybecause the results retrieval system can't process the SARIF. The GEI CLI fails at that point, instead of skipping that particular result.We've also built and tested this locally against a production migration and confirmed this works as intended.
ThirdPartyNotices.txt(if applicable)