Fix integrate-boards command to use GitHub App connections when available

[Copilot]

This PR addresses the issue where ado2gh integrate-boards fails when using GitHub PATs with broader permissions due to Azure DevOps changes implemented around June 2nd that require minimal PAT permissions for boards integration.

Problem

Azure DevOps now rejects GitHub PATs with any extra permissions when configuring boards integration, causing failures for customers who use the same PAT for both repository migration and boards integration (as recommended by our generated scripts).

Solution

The command now automatically detects and uses existing GitHub App service connections when available, falling back to PAT-based connections only when necessary. This leverages the existing GitHub App infrastructure already present in the codebase.

Key Changes

• Smart connection detection: IntegrateBoardsCommandHandler now checks for existing GitHub App service connections first
• Automatic fallback: Falls back to PAT-based approach when no GitHub App connection exists
• Proper payload handling: Sets isGitHubApp = true when using GitHub App connections
• Informative logging: Users can see which authentication method is being used
• Full backward compatibility: No breaking changes to existing workflows

Example Usage

# If a GitHub App service connection exists for the org:
ado2gh integrate-boards --ado-org myorg --ado-team-project myproject --github-org myghorg --github-repo myrepo
# Output: "Using existing GitHub App service connection for Boards integration"

# If no GitHub App connection exists:
# Output: "No GitHub App service connection found, creating PAT-based endpoint for Boards integration"

Testing

• Added comprehensive test coverage for both GitHub App and PAT scenarios
• All existing tests continue to pass (890 unit tests)
• Verified proper payload generation for both authentication methods

This change ensures that customers with existing GitHub App setups will automatically use the more reliable authentication method, while maintaining full compatibility for those still using PAT-based workflows.

Fixes #1357.

[!WARNING]

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• dev.azure.com
  • Triggering command: /usr/lib/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/OctoshiftCLI.IntegrationTests.runtimeconfig.json --depsfile /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/OctoshiftCLI.IntegrationTests.deps.json /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/testhost.dll --port 43171 --endpoint 127.0.0.1:043171 --role client --parentprocessid 5656 --telemetryoptedin false (dns block)
• https://api.github.com/orgs/octoshift-e2e-source-linux/repos
  • Triggering command: /usr/lib/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/OctoshiftCLI.IntegrationTests.runtimeconfig.json --depsfile /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/OctoshiftCLI.IntegrationTests.deps.json /home/REDACTED/work/gh-gei/gh-gei/src/OctoshiftCLI.IntegrationTests/bin/Debug/net8.0/testhost.dll --port 43171 --endpoint 127.0.0.1:043171 --role client --parentprocessid 5656 --telemetryoptedin false (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.