GitOps plugin system and a "kanvas" plugin placeholder #973
Conversation
This is the first step to add the support for kanvas as our alternative deployment tool usable by gocat. We implement the interactor and the model for kanvas almost reusing our existing InteractorKustomize and ModelKustomize. The differences between the kustomize and the kanvas supports are the "Prepare" function, which is used to edit the gitops config file in a Git repository and submit a pull request. The kustomize support does so by using gocat-builtin kustomize support. The new kanvas support does so by calling kanvas. In this change, we focus on refactoring and adding the placeholder for the kanvas support. Once this is merged, we will keep adding the actual implementation, gradually replacing the placeholder to a full-fledged feature.
| @@ -5,31 +5,36 @@ import ( | |||
| "strings" | |||
| ) | |||
|
|
|||
| type ModelKustomize struct { | |||
| type ModelGitOps struct { | |||
There was a problem hiding this comment.
We turn the existing ModelKustomize to a reusable Model implementation, that is used for building the kustomize model and the kanvas model.
| github *GitHub | ||
| git *GitOperator | ||
| plugin GitOpsPlugin |
There was a problem hiding this comment.
This is how we make it reusable; All the reusable logics reside within ModelGitOps, and tool-specific logic resides within each GitOpsPlugin like GitOpsPluginKustomize and GitOpsPluginKanvas.
A ModelGitOps instance along with GitOpsPluginKustomize works exactly same as the current ModelKustomize, so this change is backward-compatible.
| InteractorContext | ||
| model ModelKustomize | ||
| model GitOpsPlugin |
There was a problem hiding this comment.
This is how we make it reusable; All the reusable logics reside within InteractorGitOps, and tool-specific logic resides within each GitOpsPlugin like GitOpsPluginKustomize and GitOpsPluginKanvas.
A InteractorGitOps instance along with GitOpsPluginKustomize works exactly same as the current InteractorKustomize, so this change is backward-compatible.
This is about Interactor. For Model, see https://github.com/zaiminc/gocat/pull/973/files#r1395058220
| func (self ModelKustomize) Deploy(pj DeployProject, phase string, option DeployOption) (do DeployOutput, err error) { | ||
| o, err := self.Prepare(pj, phase, option.Branch, option.Assigner, option.Tag) | ||
| func (self ModelGitOps) Deploy(pj DeployProject, phase string, option DeployOption) (do DeployOutput, err error) { | ||
| o, err := self.plugin.Prepare(pj, phase, option.Branch, option.Assigner, option.Tag) |
There was a problem hiding this comment.
Deploy works in an implementation-specific way so we call out to the plugin's Prepare here.
This is the only implementation-specific part of ModelGitOps, and therefore this is the only place you see self.plugin.
For example, Commit above works regardless of the tool(kanvas, kustomize, and so on) so it doesn't call out to a plugin = no self.plugin usage.
Follow-up for kufu-ai#973 and kufu-ai#989
This is the first step to add the support for kanvas as our alternative deployment tool usable by gocat.
We implement the interactor and the model for kanvas almost reusing our existing InteractorKustomize and ModelKustomize.
The differences between the kustomize and the kanvas supports are the "Prepare" function, which is used to edit the gitops config file in a Git repository and submit a pull request.
The kustomize support does so by using gocat-builtin kustomize support. The new kanvas support does so by calling kanvas.
In this change, we focus on refactoring and adding the placeholder for the kanvas support.
Once this is merged, we will keep adding the actual implementation, gradually replacing the placeholder to a full-fledged feature.