Add support for cleaning status checks during migration

[georgy-gorelko]

Cleaning Status Checks during Migration

When migrating from Azure DevOps, both branch policies and status checks are transferred to GitHub. However, many ADO status checks are not supported in GitHub and require manual cleanup. To clean status checks from GitHub branch protection rules after migration automatically, use the --clean-status-checks option:

gh ado2gh migrate-repo --ado-org ORGNAME --ado-team-project PROJECTNAME --ado-repo REPONAME --github-org ORGNAME --github-repo REPONAME --clean-status-checks

This option will:

• Complete the normal migration process (including transferring all branch policies)
• After migration completion, automatically remove status checks from GitHub's default branch protection rules
• Preserve other branch protection settings like required reviewers, admin enforcement, etc.

Note: This is a post-migration cleanup step, so it only affects the final GitHub repository state and does not impact the migration data transfer itself.

[Copilot]

Pull Request Overview

This PR adds support for automatically cleaning status checks from GitHub branch protection rules after migration from Azure DevOps. The feature addresses the common issue where ADO status checks that are incompatible with GitHub get transferred during migration and require manual cleanup.

• Adds a new --clean-status-checks command-line option to the migrate-repo command
• Implements post-migration cleanup that removes status checks from the default branch while preserving other protection settings
• Includes comprehensive test coverage for the new functionality

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/ado2gh/Commands/MigrateRepo/MigrateRepoCommandHandler.cs	Implements the core logic for cleaning status checks from branch protection after migration completion
src/ado2gh/Commands/MigrateRepo/MigrateRepoCommandArgs.cs	Adds the CleanStatusChecks property to command arguments
src/ado2gh/Commands/MigrateRepo/MigrateRepoCommand.cs	Adds the --clean-status-checks command-line option with description
src/OctoshiftCLI.Tests/ado2gh/Commands/MigrateRepo/MigrateRepoCommandTests.cs	Adds tests for the new command option and argument handling
src/OctoshiftCLI.Tests/ado2gh/Commands/MigrateRepo/MigrateRepoCommandHandlerTests.cs	Comprehensive tests for the status check cleaning functionality
src/OctoshiftCLI.Tests/Octoshift/Services/GithubApiTests.cs	Tests for new GitHub API methods for branch protection management
src/Octoshift/Services/GithubApi.cs	Adds GitHub API methods for getting and updating branch protection rules
README.md	Documents the new feature with usage examples and explanations

[github-actions]

Unit Test Results

  1 files    1 suites   10m 24s ⏱️
952 tests 952 ✅ 0 💤 0 ❌
953 runs  953 ✅ 0 💤 0 ❌

Results for commit 3b4e544.

♻️ This comment has been updated with latest results.

[georgy-gorelko]

@boylejj can you please assign a team for this review?

[offbyone]

My impulse is to say that this kind of change is best implemented as a step in the migration itself. Is there a reason to put it in the CLI, other than "it's the part that's handy"?

[georgy-gorelko]

My impulse is to say that this kind of change is best implemented as a step in the migration itself. Is there a reason to put it in the CLI, other than "it's the part that's handy"?

It's an optional argument that we'd like to leverage migrating 1000s repos at the same time. Having enriched and flexible CLI features eliminates a need to script additional logic.

[georgy-gorelko]

@begonaguereca this can be reviewed independently as well

[brianaj]

My impulse is to say that this kind of change is best implemented as a step in the migration itself. Is there a reason to put it in the CLI, other than "it's the part that's handy"?

It's an optional argument that we'd like to leverage migrating 1000s repos at the same time. Having enriched and flexible CLI features eliminates a need to script additional logic.

I tend to agree with this being more backend logic. But in the meantime, are there screenshots of a functional test with this logic working please to make it clear what this does?

[georgy-gorelko]

My impulse is to say that this kind of change is best implemented as a step in the migration itself. Is there a reason to put it in the CLI, other than "it's the part that's handy"?

It's an optional argument that we'd like to leverage migrating 1000s repos at the same time. Having enriched and flexible CLI features eliminates a need to script additional logic.

I tend to agree with this being more backend logic. But in the meantime, are there screenshots of a functional test with this logic working please to make it clear what this does?

Sure, I can provide some screenshots of examples prior the change and after the change.
ADO status check policy being transferred to GitHub does not trigger any evaluation as such blocks further merge. Here an example:

GitHub status checks enforced after migration from ADO:

ADO Status checks set by policy:

This PR clears ADO status checks from GitHub policy. Those checks will be introduced and enforced by owning teams to support in GitHub

[brianaj]

@georgy-gorelko and what is the before and after of running with this flag, want to understand what settings were migrated incorrectly and what we are cleaning up.

[brianaj]

@georgy-gorelko also thoughts on using something like this https://github.com/katiem0/gh-branch-rules which should solve your problem and then would allow us to fix this properly on the backend (as it seemingly is a bug).

Also sorry for multiple questions when you stated many ADO status checks are not supported in GitHub and require manual cleanup., is there a known list of ADO status checks that are compatible with GitHub?

[georgy-gorelko]

@georgy-gorelko and what is the before and after of running with this flag, want to understand what settings were migrated incorrectly and what we are cleaning up.

Require status check for above (shown in screenshot) blocks all PRs. ADO status checks for custom checks not supported in GitHub (Example: ADO code coverage, Component Governance, etc). Github has its own version of these checks implemented and supported as such ADO transition is unnecessary and requires manual cleanup/disablement upon migration.

[georgy-gorelko]

@georgy-gorelko also thoughts on using something like this https://github.com/katiem0/gh-branch-rules which should solve your problem and then would allow us to fix this properly on the backend (as it seemingly is a bug).

Also sorry for multiple questions when you stated many ADO status checks are not supported in GitHub and require manual cleanup., is there a known list of ADO status checks that are compatible with GitHub?

Upon migration I have found that ADO status checks hang on waiting status. My understanding is that these checks from ADO have no report back to GitHub and simply need to be regenerated by GitHub rulesets.

https://github.com/katiem0/gh-branch-rules lists/updates GH repo policies but doesn't correlate ADO status checks being transferred during migration process. Thus cleaning upon ADO to GH migration required.

[georgy-gorelko]

Any concerns on merging this PR?

[brianaj]

Any concerns on merging this PR?

@georgy-gorelko I started discussion with team as this seems like something better handled on backend. From my understanding, we don't need to migrate these status checks for ADO, and if that is the case we should handle that in our core migration logic.

[brianaj]

@georgy-gorelko I'm working on a backend change that will not migrate these status checks for ADO, as they are seemingly not compatible with GitHub.

[brianaj]

@georgy-gorelko do you have a test org you are using for testing this migration behavior?

[brianaj]

@georgy-gorelko as mentioned I will be out of office soon so whoever has bandwidth from the team will pick up my PR I created on the backend to achieve this functionality. We will just need your test org name for you to test once shipped.

[georgy-gorelko]

@georgy-gorelko as mentioned I will be out of office soon so whoever has bandwidth from the team will pick up my PR I created on the backend to achieve this functionality. We will just need your test org name for you to test once shipped.

I do testing in our prototype project https://msdyneng.visualstudio.com/RuneDevOps. Not sure if you have an access to it. I can assist with testing though

[begonaguereca]

We are merging in https://github.ghe.com/github/octoshift/pull/11209 which takes care of handling this logic in the GEI backend 👍🏽

[georgy-gorelko]

Closing PR given above PR was raised. Will reopen if issue still persists

[georgy-gorelko]

Reopening given status checks still blocking PRs after the migration

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
ado2gh	72%	69%	752	➖
Octoshift	83%	72%	1718	✔
bbs2gh	83%	77%	653	✔
gei	80%	72%	574	✔
Summary	80% (7757 / 9643)	72% (1833 / 2529)	3697	✔

[georgy-gorelko]

@brianaj @begonaguereca status checks still transfer during the migration that require manual undo. Can you please confirm that backend changes committed and verified? Otherwise let me know if I can proceed with current PR