Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add delete provider command #2922

Merged
merged 2 commits into from
Apr 4, 2024
Merged

Conversation

eleftherias
Copy link
Contributor

Summary

This adds the minder provider delete command, with the option of passing a provider ID or name.
The command will delete the provider from the DB, delete all associated repos, remove the repo webhooks and uninstall the GitHub App from the GitHub org, if it is a GitHub App provider.

Fixes #2897

Change Type

Mark the type of change your PR introduces:

  • Bug fix (resolves an issue without affecting existing features)
  • Feature (adds new functionality without breaking changes)
  • Breaking change (may impact existing functionalities or require documentation updates)
  • Documentation (updates or additions to documentation)
  • Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

  • Reviewed my own code for quality and clarity.
  • Added comments to complex or tricky code sections.
  • Updated any affected documentation.
  • Included tests that validate the fix or feature.
  • Checked that related changes are merged.

@coveralls
Copy link

coveralls commented Apr 3, 2024

Coverage Status

coverage: 48.298% (+0.3%) from 48.035%
when pulling ccbf3a2 on eleftherias:delete-provider
into 11c13c2 on stacklok:main.

@eleftherias eleftherias requested a review from dmjb April 3, 2024 13:38
Copy link
Member

@evankanderson evankanderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only real question / concern is whether we want the logic of deleting dependent repositories (but not other types of things a provider might be responsible for) to live in controlplane, or to push that down into the providers implementation.

cmd/cli/app/provider/provider_delete.go Show resolved Hide resolved
Comment on lines +235 to +248
if p.Implements(db.ProviderTypeGithub) &&
providers.GetCredentialStateForProvider(ctx, *provider, s.store, s.cryptoEngine, &s.cfg.Provider) ==
provinfv1.CredentialStateSet {
client, err := p.GetGitHub()
if err != nil {
return status.Errorf(codes.Internal, "error creating github provider: %v", err)
}

// Delete all repositories associated with the provider and remove the webhooks
err = s.repos.DeleteRepositoriesByProvider(ctx, client, provider.Name, projectID)
if err != nil {
return status.Errorf(codes.Internal, "error deleting repositories: %v", err)
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like it should be a part of the DeleteProvider implementation, rather than in ControlPlane. e.g. GitHub providers should understand that they need to clean up webhooks, but other types of providers might have other types of cleanup they need to do.

(e.g. we talked about DeleteProvider for GHA un-installing the app from the org.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had written it like that initially, but then providerService needed to use the repositoryService which seemed wrong. We could also call the store directly to delete the repositories, but then there will be duplicate logic in the services.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's totally reasonable for different services to call eachother - some domain concepts are at a higher level of abstraction than others, and thus delegate to the services for the lower-level domain concepts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems there were some recent changes that also now create an import cycle when I try that:

package github.com/stacklok/minder/internal/providers
	imports github.com/stacklok/minder/internal/repositories/github
	imports github.com/stacklok/minder/internal/logger
	imports github.com/stacklok/minder/internal/engine/actions/alert
	imports github.com/stacklok/minder/internal/engine/actions/alert/security_advisory
	imports github.com/stacklok/minder/internal/providers: import cycle not allowed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we can resolve the cycle, but it's not something I want to spend time too much time on now. Can we live with this logic in the controlplane for now and do a followup PR to refactor?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm okay with that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the import cycle, I'd probably break the logger --> actions/alert import path, but happy to do that as a follow-up.

Comment on lines +429 to +436
privateKey, err := p.config.GitHubApp.GetPrivateKey()
if err != nil {
return fmt.Errorf("error getting GitHub App private key: %w", err)
}
jwt, err := credentials.CreateGitHubAppJWT(p.config.GitHubApp.AppID, privateKey)
if err != nil {
return fmt.Errorf("error creating GitHub App JWT: %w", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines are shared with getInstallationOwner on 430 -- it feels like this should be a method.

getInstallationTokenCredential has a slightly different path to the same outcome, but might be the right tool for the job as it covers 417-436, with the chance of returning an EmptyCredential.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This is a small nit, and we can fix it later)

evankanderson
evankanderson previously approved these changes Apr 3, 2024
Comment on lines +235 to +248
if p.Implements(db.ProviderTypeGithub) &&
providers.GetCredentialStateForProvider(ctx, *provider, s.store, s.cryptoEngine, &s.cfg.Provider) ==
provinfv1.CredentialStateSet {
client, err := p.GetGitHub()
if err != nil {
return status.Errorf(codes.Internal, "error creating github provider: %v", err)
}

// Delete all repositories associated with the provider and remove the webhooks
err = s.repos.DeleteRepositoriesByProvider(ctx, client, provider.Name, projectID)
if err != nil {
return status.Errorf(codes.Internal, "error deleting repositories: %v", err)
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the import cycle, I'd probably break the logger --> actions/alert import path, but happy to do that as a follow-up.

@eleftherias eleftherias merged commit ef50b29 into mindersec:main Apr 4, 2024
20 checks passed
@eleftherias eleftherias deleted the delete-provider branch April 4, 2024 09:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add provider delete command
5 participants