Discussion: Future of GitOps CLI to transform to a developer and end-user centric CLI

[niiku]

Currently, the purpose of the GitOps CLI is to be used in a CI system to copy/change YAML and talk to the Git provider API. As already indicated in #104 I would like to discuss the future of the CLI to make the whole GitOps ecosystem around it more available to developer and new users.

Bootstrapping

A new user should be able to bootstrap the whole GitOps ecosystem using the CLI. This includes:

• Provisioning of the app-of-apps repository (apps-root-config)
• Provisioning the cluster-infra-apps repository
• Installation and configuration of Argo CD in the cluster-infra-apps repository
• Add CLI commands to add new config repositories
• Possible additions:
  • Installation support for SealedSecrets
  • Make the use of the GitOps ecosystem usable without the need to configure a CI system (apps-sync, preview envs) add support for a REST API which would be configured as webhook
  • Support for Monitoring Stack

Context Support

Currently a lot of the commands would be hardly usable if they’re used outside of a CI system due to the high amount of arguments. As I would like to see the GitOps CLI as a utility for developers to make common task easily executable. To reduce the amount of arguments which are required the context should be stored in a config file. As design inspiration I would orient on how kubectl or oc manage their contexts. This would include:

• Support for a login/init process which creates a config file storing:
  • References to the app-of-apps repository
  • Git credentials
  • User / Email – maybe taken from .gitconfig
  • Available config repositories to the user
• Support for context switching (between app-of-apps repository or config-repositories)

For the use in a CI system a config file could simply be passed either through a parameter or an env variable.

Developer Support

Besides the existing commands like create-preview the following features would round off the experience of the GitOps ecosystem

• Add reflection commands like get config-repos or get environments including the health status from Argo CD
• Add environment creation support like create environment –name demo-test –image org/app:latest –host app.example.tld. Some defaults like which environment template should be used could be stored in the app-of-apps repository (reference to generic-chart)
• Add environment deletion support
• Add promotion support (promote test to int) like promote –from demo-test –to demo-prod )
• Provide debugging utilities which could help identify issues of the deployment (duplicate environment name, Argo CD Health status etc.)
• Environment migration / duplication support (e.g. moving an environment between two config repositories, create new environments based on an existing one)

The order of how I wrote the ideas have nothing to do with the possible priority. What are you guy thoughts about how we should move on? @christiansiegel @joachimprinzbach

[christiansiegel]

Bootstrapping

This sounds like a platform team internal tool. Is it really helpful to add and especially maintain those features in the gitopscli? IMO this feels like the wrong tool for the job 🤔 Why not create a separate bootstrap tool for that? Also because you can hard-code a lot more if only used internal.

Context Support

If we would have a binary (#104) this could make sense. In case of the current docker image, mounting a config file feels a bit cumbersome. But why not...

Developer Support

• reflection commands: how should the gitopscli know where to find our config repos?
• environment creation: aren't most real-life environments way more complex than that? Does it really help the developer? I mean everyone should be able to copy the minimal example from our tutorial
• environment deletion: again - deleting a folder is not that hard
• promotion: do I really want to promote everything? For example I probably don't always want to promote the number of replicas -> this will make it very hard to provide a generic promote command
• debugging utilities: I guess it is easier to open the ArgoCD UI
• environment migration: this is as hard as copying a folder

To sum it up: I don't see the benefit of adding much more features because of the following reasons:

• high amount of work to add and maintain those features. Especially if they should cover more then the "demo use-case".
• IMO the developers should know how the deployments work. We should invest our time in creating (and constantly updating!) our tutorials and documentation. Adding another layer between the developer and the gitops config will not help. (Well, maybe it slightly speeds up the power users..but at what cost?)
• Also, as we heavily rely on contributions from non-maintainers, we should keep the gitopscli as simple as possible. It already is confusing enough for the 1st time contributor.

[joachimprinzbach]

Would close thise one for the moment