How about gitops cli tool ?

[vijaySamanuri]

We have several environment stages at our place but gitops doesn't cover the promotion part among these stages.
As a workaround we adopted "branch per environment" strategy and rotating the PR to the other environment but these all are manual steps and when we script this to CI system its all non standard i.e different CI system requires different way of doing it for example github actions requires different way of doing it, gitlab plugin different way.

I think it is beneficial to have a standard cli tool something like gitops which deals with all the manual steps during the gitops deployment process. This tool just interacts with the underlying git tool and wraps the gitops specific git commands.

for example:

gitops init hld --for-app=guestbook would initiate the HLD repository if not present
gitops env add stage would create a stage branch in HLD repository
gitops raisePR prod --from=stage raises a PR from stage branch to prod branch
gitops rollback prod
etc

[vijaySamanuri]

@scottrigby Scott Rigby any thoughts on this? Tell me in case if it is irrelevant and out of scope ?

[lloydchang]

@vijaySamanuri @ams0 @tonit @scottrigby

I believe @vijaySamanuri's request is out of scope because:

gitops raisePR would mostly be in conflict with a goal from the GitOps Working Group Charter:

Goals
• Project/vendor neutral.

---

My reasons are:

1. The only Git pull request tooling that is vendor neutral is:

git git-request-pull

described at https://git-scm.com/docs/git-request-pull

In practice, git git-request-pull is project specific, such as https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html

2. Most pull request tooling have vendor bias, often driven by market share and rate of adoption.

Even alternatives to pull requests, such as Gerrit code reviews, references GitHub because of popularity.

For example:

Basic Gerrit Walkthrough — For GitHub Users
Note: This document aims to provide a concise description of the core principles of code review in Gerrit for people that were previously using Pull Requests on Github or similar concepts. Nothing in this document is meant to state that one or the other might be better, but only aims to help new users understand Gerrit more readily. We use Github as the point of comparison since it seems to be the most popular service.

3. While Git facilitates GitOps, Git is optional.

If desired, other revision control systems, such as Mercurial and Subversion, can be used instead of Git.

---

Thank you @vijaySamanuri @ams0 @tonit @scottrigby

[ams0]

Isn't the whole point of GitOps to manage infrastructure and applications via git? Is it not then that you really only need:

git init
git branch staging
gh pr create #Github CLI
git reset --soft HEAD~1

?

[lloydchang]

The objective of GitOps is convergence to a declarative state.

While Git facilitates GitOps, Git is optional.

This relates to https://github.com/gitops-working-group/gitops-working-group/discussions/76#discussioncomment-633924

Thank you @ams0

[scottrigby]

I'd suggest re-opening this as a discussion topic now that #36 is set up. I'd convert it for you, but for the moment we can't due to community/community#2924 (comment).

[scottrigby]

Converted this issue to a Discussion proposal.

[tonit]

I agree with @ams0 that "pull request driven operations" really seem to be the theme around gitops.

Still i can imagine that imperative CLI tools have its place when carefully crafting/shaping pull requests.

Similar to tooling around GitFlow you want to automate most (boring) tasks such as templating a (common) change, testing, managing potential dependencies between PRs etc.

WDYT?

[lloydchang]

@tonit If your focus is on pull requests, then this relates to https://github.com/gitops-working-group/gitops-working-group/discussions/76#discussioncomment-633924

The objective of GitOps is convergence to a declarative state.

If your focus is on operations, then are the following CLIs sufficient?

Argo CD CLI:
• https://argoproj.github.io/argo-cd/getting_started/#creating-apps-via-cli

Flux v1 CLI:
• https://docs.fluxcd.io/en/1.22.1/references/fluxctl/

Flux v2 CLI:
• https://toolkit.fluxcd.io/cmd/flux/

Keptn CLI:
• https://keptn.sh/docs/0.8.x/operate/install/

Thank you @tonit

[scottrigby]

There is some new thinking on this, and it was discussed in the most recent GitOps WG meeting. There is some talk about this as a shared CLI command, where support for specific tools would be added through plugins.

The idea is this would live in the OpenGitOps project. See #77

This is not an answer yet, just a note that there is some movement here, and will probably move to https://github.com/open-gitops/project/discussions. Keeping this open until it's started there.

[lloydchang]

Thank you @scottrigby

When your time permits, here is a wall of text 😄

I tried looking up July's recording at https://www.youtube.com/channel/UCI6iqYuuI4gZuOCZaks5i1g/videos to learn what was discussed, but I couldn't find any uploaded recordings after May.

I did find meeting notes at https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit and I see that OCI was mentioned as an example on July 21st. Practically-speaking, OCI's cornerstone was runC donated by Docker, summarized at https://opencontainers.org/about/overview/

Since Flux didn't integrate into GitOps Engine, Flux and Argo are two different implementations of GitOps.

I don't see any issue with multiple implementations.

As for CLI examples, growth, and evolutions: I suppose one can try using sed for UNIX, Edlin for DOS, but those CLIs didn't serve the broader needs that vi and emacs cover. vi and emacs have co-existed for decades as different implementations of editors that serve needs that CLIs don't. They each serve their own purpose based on people's preferences.

Although I feel and think that GitOps ecosystem has grown and evolved beyond just a gitops CLI, let's go back to the topic of CLI for the sake of this discussion open-gitops/gitops-working-group#76.

A number of questions come to mind:

1. Curiously, who would maintain a CLI?
2. Has GitOps WG considered bash shell aliases to satisfy the immediate needs discussed above?
3. Does GitOps WG prefer typing long-form gitops instead of shell aliases such as g for git, f for fluxctl, a for argocd, k for kubectl, etc.?
4. If not bash shell aliases, then which programming language would GitOps WG write the gitops CLI in?
5. Which target operating systems would the gitops CLI compilation target?
6. Is this turning into over-engineering?
7. Is this conversation trending into bikeshedding?
8. The point I'm getting at is that the best software code can be code that doesn't need to be written in the first place.
9. I believe the problem space can be solved in more important ways, such as education and training about using software in GitOps Landscape even over creating and maintaining just a gitops CLI.

Thank you for reading 😄

[lloydchang]

@vijaySamanuri wrote:

gitops init hld --for-app=guestbook would initiate the HLD repository if not present

---

While I was reviewing:

GitOps Working Group - Overview and Invitation.

Video referenced https://github.com/podtato-head/podtato-head/ for the purpose of 📨🚚 CNCF App Delivery SIG Demo.

From https://github.com/podtato-head/podtato-head/blob/main/README.md

Project pod tato Head
Podtato-head demonstrates cloud-native application delivery scenarios using many different tools and services. It is intended to help application delivery support teams test and decide which mechanism(s) to use.

There is an entry:

GitOps deployment via Gimlet CLI

Perhaps gimlet gitops bootstrap described at https://gimlet.io/gimlet-cli/bootstrap-gitops-with-gimlet/ has similar mechanics that you expect from gitops init?

From your perspective, would both gitops init and gimlet gitops boostrap operate at the same level of abstraction?

WDYT?

Thank you!