Migrate GHAS Alerts

[dylan-smith]

When migrating repos, any secret/code scanning/dependabot alerts currently don't migrate. Sure you can run a new scan on the target repo, but if you have dismissed any alerts as false positive (for example), that information will be lost.

Our friends over in GitHub services have written some code that does exactly this, and this issue represents incorporating that capability into this CLI.

The existing code (in typescript) can be found here (note: not accessible by non-github staff): https://github.com/octodemo/daves-gei-playground

Tasks

• [x] #535
• [x] #536
• [ ] #537

Implementation Guidance

We have established patterns in the CLI codebase, that I'm going to try to briefly rehash the relevant bits here.

We have a GithubApi class that wraps GH api endpoints. Generally one function in that class for each API endpoint. There should be very little logic in those functions, they know what the endpoint URL is, and they know how to craft the proper payload, and parse any response (e.g. GetCodeScanningAnalysis(...) ListSecretScanningAlerts(...)).

We have Command classes for each CLI command. In general the Command classes should also be very "thin", and mostly contain the definition of the args/help text, validate the arguments, then call either the *Api classes if the command is mostly a wrapper over an api call or two, or if there is significant logic that needs to be implemented that should live in a service class which the command class will call (which in turn will call *Api classes). For this work I expect both of the new commands will need a Service class to implement the necessary logic. An example of an existing command that uses this service pattern is the ReclaimMannequinCommand.

[dylan-smith]

I didn't include a task for it yet, but I imagine migrating dependabot alerts could/should be done using a similar approach?

[davelosert]

I just changed the visibility of the repo (https://github.com/octodemo/daves-gei-playground) to internal, so anyone at GitHub should be able to see it now.

[davelosert]

@dylan-smith : There are two reasons why I didn't include depndabot yet:

1. The API does not allow us to migrate the alerts themselves, so we are not able to receive any historical alerts. And other than with secret-scanning, you can't surface those historical alerts by running Dependabot again as this will only alert for vulnerabilities that are still in the current version of the repository. So the only thing that could be migrated would be dismissal states of those - and we saw only very little value in this

2. Right now, the Dependabot API is only on GraphQL, so it would have been a bit more work to get another abstraction for that in.

However, implementing what is possible should be trivial, so maybe we can include this after the rest is done.