GoogleContainerTools/skaffold

Clean up from remote repositories as well after skaffold-dev

Ouverte

#3 487 ouverte le 9 janv. 2020

Voir sur GitHubGuide contributeur
 (5 commentaires) (1 réaction) (0 personne assignée)Go (1 416 forks)batch import
area/cleanuphelp wantedkind/feature-requestpriority/p3

Métriques du dépôt

Stars
 (12 822 étoiles)
Métriques de merge PR
 (Merge moyen 3j 6h) (16 PRs mergées en 30 j)

Description

Hi. I have been using a remote GKE cluster as my development target since its difficult to run Minikube and test everything on my system. Everything works great with skaffold dev pushing images remotely during development and I am able to test it.

But, when terminating skaffold dev I would like the remote GCR images which were pushed to be cleaned up as well to avoid doing it manually later. Too many tags are getting pushed to GCR because of this.

Rather, all tags can be stored in the remote registry permanently only when running skaffold run but cleaned up when using skaffold dev

Is there any other way to avoid issues like these? Thanks. I hope the GCloud bill doesn't shoot up because of this.

Guide contributeur

Direction de recherche
Cette demande de fonctionnalité demande le nettoyage des images poussées à distance après la fin de `skaffold dev`. Pour implémenter, explorez le cycle de vie de skaffold dev dans `cmd/skaffold/app/cmd/dev.go` et la logique de nettoyage dans `pkg/skaffold/deploy`. Le nettoyage actuel supprime les conteneurs locaux mais ne supprime pas les images du registre distant. Envisagez d'ajouter une étape pour supprimer les tags poussés via l'API GCR en utilisant le nom du dépôt et les tags stockés pendant dev. L'interface de déploiement existante peut nécessiter une extension. Consultez également les commentaires de discussion pour des contraintes supplémentaires.
Stack technique
go
Domaine
backendclouddevops
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GoKubernetesGCP
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
50