devstream-io/devstream

DevStream: the open-source DevOps toolchain manager (DTM).

DevStream

to be updated

devstream's Issues

🍀 `Proposal`: see if we can use argocd API/SDK to create the application CRD instead of using kubectl apply

Question

At the moment, in the argocdapp plugin, we create the ArgoCD app CRD by using kubectl apply -f, which is not ideal.

Do some research and see if it's possible to create the CRD by using ArgoCD Golang SDK/API.

Only research (and maybe a test-drive is needed, no need to implement immediately)

E2E Testing

Done-Done Checklist

DTM

• all dtm params tested

GitHub Actions Plugin

• GitHub Actions plugin install from scratch
• GitHub Actions plugin re-run (install/apply again; reinstall) should not cause any error
• proper logging messages should be available (for example, xxx pipeline already exists and nothing is changed, etc.)

ArgoCD Plugin

• ArgoCD plugin install with existing namespace
• ArgoCD plugin install without existing namespace
• ArgoCD plugin reinstall shouldn't change anything
• proper logging messages should be available

ArgoCD App Plugin

• ArgoCD app plugin install
• ArgoCD app plugin reinstall shouldn't change anything
• ArgoCD app plugin install without ArgoCD should give a proper warning (CRD doesn't exist; ArgoCD not installed, etc.)

Automated E2E Testing Investigation

• automated test locally (with minikube, etc.)
• possibility to create a cluster in a container as part of the GitHub actions workflow
• create a small cluster in the cloud with minimum cost (for example, automatically shut down when not used; create/destroy on the fly; etc.)

---

@lfbdev @daniel-hutao, please think about it and add more to the list. We can create a test plan for each plugin in the future based on the list.

Create a new plugin for GitLab CI

Description

Similar to the github actions plugin, we might need one for GitLab CI.

init and install logic improvement:

What should happen when install is called without calling init first?

Shall we run the init anyway for the user, or only a warning should be given and let the user take control of the whole process?

We can refer to other open-source tools, like Terraform init/apply.

bug: The logs in the plugins disappeared

Describe the Bug

The logs in the plugins disappeared. See the screenshot below for the details.

For now, maybe we should return all error messages to the core(dtm) module instead of printing them to stdout.

How to Reproduce

./dtm install -f xxx.yaml

Screenshots

Implement uninstall/reinstall interface for githubactions plugin

Description

At the moment, the Reinstall and Uninstall are mocks.

We want to implement them.

Describe the Proposal

Reinstall: no matter if the workflows are created or not, overwrite it.

Uninstall: delete the pipelines (if already created)

Add documentation for the current three plugins

Scope

At the moment, we have three plugins:

• argocd
• argocdapp
• githubactions

We need one document for each plugin.

Describe the Change

Maybe creating a subfolder named plugins under docs, then one document for each plugin?

Each doc should contain a sample config, what parameters are mandatory, sample values, etc.

Add containerized build support

Description

We should move the compile/build process to a container to ensure that everyone can get consistent products. Local compile/build often introduces problems due to inconsistent environment, such as inconsistent golang versions.

Describe the Proposal

1. Adding golang:1.17.x as a builder container.
2. Updating Dockerfile & Makefile.
3. ...

Proposal: Add a concurrent-safe map to improve the concurrency security of the state management module

Description

sync.Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination.

sync.Map is more reliable and efficient than default build-in Map + Mutex.

Describe the Proposal

• Adding a ConcurrentMap type to package sync.Map & keyType & valueType
• Change States to StatesMap, States & State are a bit confusing
• Use ConcurrentMap with keyType string & valueType *State to redefine StatesMap

Adding a "planning decision" feature to determine the next action

Description

Adding a "action calculation" feature to determine the next action based on the current States of the environment and the input Config.

Describe the Proposal

When the state management function is integrated into the main branch #28 , we need to use the States in the next step, that is, an algorithm is needed to determine the specific actions each time the dsm is executed.

The general idea is as follows:

type ActionFunc func(tool *config.Tool) (bool, error)

type Plan struct {
	Changes []*Change
}

type Change struct {
	Tool   *config.Tool
	Action ActionFunc
}

func MakePlan(smgr statemanager.Manager, cfg config.Config) *Plan {...}

// ......
func TestMakePlan() {
	// ......
	plan := MakePlan(smgr, cfg)
	for _, change := range plan.Changes {
		change.Action(change.Tool)
	}
}

Research: github actions plugin - download the workflow yaml on the fly instead of storing them in variables

Description

At the moment, the workflows for github actions plugin are hard-coded and stored in variables.

Evaluate the possibility to download (http, git api, etc) from here instead of storing everything as a variable.

If downloading is possible, we need to handle retries/exponential backoff, so we might need to dig into some open-source go modules for these capabilities.

Only research is OK, maybe a small MVP, no need to implement right away.

Add CLA (Contributor License Agreement) for DevStream

Scope

Add CLA (Contributor License Agreement) for DevStream

Additional Context

• https://en.wikipedia.org/wiki/Contributor_License_Agreement
• https://github.com/cncf/cla/blob/master/individual-cla.pdf
• https://opensource.com/article/18/3/cla-vs-dco-whats-difference

Add some unit tests for both core and existing plugins

Description

Add the right amount of unit tests, so that when the CI build passes, we are certain that the quality is good enough to be merged into main.

Plugin Download Logic improvement:

check md5sum of existing local plugins, then decide if a download is needed or not;
if a local plugin exists, but the version differs, delete local, then download the correct version.

Add "Code of Conduct" for DevStream

Scope

Add "Code of Conduct" for DevStream

Screenshots

Refactor: cmd and pluginengine Refactor

Description

Current situation:

• most logic (download plugins, create a backend, read state, create a plan and execute it) all lives in the cmd/devstream/install.go; the internal/pkg/pluginengine doesn't do much except load the so and execute the corresponding interface
• plan generation code lives in stream/internal/pkg/planmanager/result.go which doesn't seem right according to the name
• plan generation calls the engine instead of the other way around

Describe the Proposal

• move the main logic out of the cmd/devstream package and into the internal/pkg/pluginengine package
• pluginengine as the main entrance (as shown in the architecture diagram)
• figure out a way so that plan doesn't call engine, but the other way around, so that:
• pluginengine initiates config loading, plugin downloading, plan creating/executing, and state managing

Change install command to create/apply

Description

Maybe we need to change the install command to create/apply because the uninstall operation can be triggered during the execution of the install command, so the install command is confusing.

In addition, the delete operation may require more consideration. If the user accidentally specifies an empty configuration file, after executing the dtm command, all installed components will be uninstalled, which may not be what they want. We may need to provide a separate command for the uninstall action, such as the delete command, to let users know the real result of their command action.

I consider solving the first problem mentioned above first - rename the install command.
Then modify the planmanager so that create/apply does not trigger the uninstall action.
Finally, add a separate uninstall/delete command entrance.

/kind proposal
/assign @daniel-hutao
/cc @merico-dev/devstream

Done-Done Check

• interfaces not changed
• command change to apply and delete
• document update (readme, etc)

Architecture Diagram Update

Making sure the name and architecture match the implementation.

Proposal: Add a `--force` flag support

Description

dtm install -f config.yaml --force

Describe the Proposal

Describe the Alternatives You Have Considered

Implement uninstall/reinstall interface for argocdapp plugin

Description

At the moment, the Reinstall and Uninstall are mocks.

We want to implement them.

Describe the Proposal

Reinstall: kubectl apply again

Uninstall: kubectl delete crd xxx

Adding air-gapped installation support.

Description

We need to provide a mechanism to support users to use in an air-gapped or a bad network environment.

Maybe we could provider a shell script like offline-tool.sh & text file like resource.txt. These 2 file could:

1. resources.txt maintain all resources dsm needed when deploy a new env. Users can customize the content of this file to decide that they need to download all or part of the resources.
2. offline-tool.sh can download all resources listed in resources.txt

file structure may like below:
stream

• hack/ (or script?)
  • offline-tool.sh
  • resources.txt

bug: statemanager delete a State when uninstall failed.

Describe the Bug

statemanager delete a State when uninstall failed.

How to Reproduce

1. install a plugin
2. uninstall a plugin but failed with some error
3. look into devstream.state file

Expected Behavior

state file hold the State with uninstall failed

CLI Tool and Packages Rename

Done-Done Checklist

1. CLI rename from dsm to dtm

2. Packages and directories renaming:

download to pluginmanager or similar (for example plugindownloader, so that it's consistent with statemanager (functions-verb-er);

plugin to pluginengine

config to configloader

plan to planmanager

3. Doc update (@IronCore864)

DevStream Core: plugin management

Description

At the moment, the plugins must be placed in a specific directory and must be compiled/built by users before using the CLI tool.

We can build the CLI and the plugins and publish them into GitHub releases.

For more information, check out this discussion here:

https://github.com/merico-dev/stream/discussions/26

Done-Done

1 Add an init Command to dsm

Add some commands like dsm init -f config.yaml, which:

• parses the config file and collect all plugins' names and versions
• decides a local directory (for example .dsm/plugins/) then download the needed plugins with the correct version from GitHub releases public URL

2 Downloading Logic

The idea is simple: only download when necessary.

• if the dir for local plugins doesn't exist, create it first
• if a plugin already exists locally, there is no need to download it again
• if a plugin exists, but the version isn't correct, delete it and download the new one

Maybe I'm missing something here, please have a look @lfbdev @daniel-hutao

There could be a possibility to improve: md5sum before download to ensure the local plugin is the desired one (no need to implement now).

3 Some other Quality-of-Life (QoL) Improvements

If dsm init isn't executed, but dsm install is executed, either a hint should be printed out to let the user to init it first, or the init will be called automatically before install is called.

4 Testing and Documentation

Add UT for the init/download part, especially the download logic part because it will be changed probably in the future.

For documentation, please write a Chinese version (no need to be put in the repo) and I will translate it into English.

Implement uninstall/reinstall interface for argocd plugin

Description

At the moment, the Reinstall and Uninstall are mocks.

We want to implement them.

Describe the Proposal

Reinstall: helm upgrade --install
Uninstall: helm delete

Proposal: Make the uninstall operation idempotent

Description

Take argocdapp as an example. If this plugin has been uninstalled, the uninstall operation will fail at this time.

Describe the Alternatives You Have Considered

Handle the error like below

Error from server (NotFound): error when deleting "./app.yaml": applications.argoproj.io "hello" not found

/kind proposal

Failed to install argocd

Describe the Bug

Got unexpected EOF error when using dsm to install argocd.

How to Reproduce

1. Prepare config.yaml and put it in /tmp/config.yaml

---
tools:
- name: argocd
  version: 0.0.1
  options:
    repo:
      name: argo
      url: https://argoproj.github.io/argo-helm
    chart:
      name: argo/argo-cd
      release_name: argocd
      namespace: argocd
      create_namespace: False

2. Execute ./dsm install -f /tmp/config.yaml
3. Got unexpected EOF error.

Screenshots

bug: githubactions "delete" failed with no "sha" error

Describe the Bug

githubactions "delete" failed with no "sha" error

2021/12/28 10:42:42 DELETE https://api.github.com/repos/daniel-hutao/animal/contents/.github/workflows/pr-builder.yml: 422 Invalid request.

"sha" wasn't supplied. []

How to Reproduce

uninstall or reinstall a githubaction

Screenshots

reflactor: Create a New `plugin` Package to Store the Code with All the Built-in Plugins

Description

I think that we could create a new plugin package to store the code with all the built-in plugins and the pluginengine.
The pkg tree now is like below:

internal/pkg/
	argocd
	argocdapp
	backend
	configloader
	githubactions
	planmanager
	pluginengine
	pluginmanager
	statemanager
	version

The packages with the build-in plugins will be more and more. Maybe putting them under one package will make it clearer. Just like below:

internal/pkg/
	plugin/
		argocd
		argocdapp
		githubactions
	backend
	configloader
	planmanager
	pluginengine
	pluginmanager
	statemanager
	version

/kind proposal
/cc @merico-dev/devstream

proposal: put goimports... into GitHub Actions base image.

Description

The Makefile now is:

fmt: ## Run go fmt against code.
	go get golang.org/x/tools/cmd/goimports
	goimports -local="github.com/merico-dev/stream" -d -w cmd
	goimports -local="github.com/merico-dev/stream" -d -w internal
	go fmt ./...

Maybe we can re-choose a base image containing goimports or customize our own base image with more tools.

bug: xxs - log format error at downloading plugin

Describe the Bug

Some logs like below:

now downloading plugin: githubactions_0.0.1-rc1.so ,version: 0.0.1-rc1

Try to make it more beautiful.

/kind bug
/assign @lfbdev

Bug: failed to uninstall argocdapp clean

Describe the Bug

Failed to uninstall argocdapp.
These resources should be cleaned up by the operator, but at this time the operator has been deleted.
It should be solved after we have the dependency manager.

~/MyGolangProjects/stream/demo   main  ./dtm install -f ./empty.yaml
2021/12/29 22:31:26 succeeded to initialize States
2021/12/29 22:31:26 added a change: argocdapp -> uninstall
2021/12/29 22:31:26 added a change: githubactions -> uninstall
2021/12/29 22:31:26 added a change: argocd -> uninstall
2021/12/29 22:31:26 changes count: 3
2021/12/29 22:31:26 processing progress: 1/3
2021/12/29 22:31:26 processing: argocdapp -> uninstall
2021/12/29 22:31:26 application.argoproj.io "hello" deleted
2021/12/29 22:31:26 processing progress: 2/3
2021/12/29 22:31:26 processing: githubactions -> uninstall
2021/12/29 22:31:26 language is go-1.17
2021/12/29 22:31:30 deleting github actions Workflow pr-builder.yml...
2021/12/29 22:31:31 github actions Workflow pr-builder.yml removed
2021/12/29 22:31:31 deleting github actions Workflow master-builder.yml...
2021/12/29 22:31:32 github actions Workflow master-builder.yml removed
2021/12/29 22:31:32 processing progress: 3/3
2021/12/29 22:31:32 processing: argocd -> uninstall
2021/12/29 22:31:32 uninstalling argocd helm chart
2021/12/29 22:31:32 uninstall: Deleting argocd
2021/12/29 22:31:34 Starting delete for "argocd-redis" Service
2021/12/29 22:31:34 Starting delete for "argocd-repo-server" Service
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" Service
2021/12/29 22:31:34 Starting delete for "argocd-server" Service
2021/12/29 22:31:34 Starting delete for "argocd-dex-server" Service
2021/12/29 22:31:34 Starting delete for "argocd-redis" Deployment
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" Deployment
2021/12/29 22:31:34 Starting delete for "argocd-server" Deployment
2021/12/29 22:31:34 Starting delete for "argocd-dex-server" Deployment
2021/12/29 22:31:34 Starting delete for "argocd-repo-server" Deployment
2021/12/29 22:31:34 Starting delete for "argocd-dex-server" RoleBinding
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" RoleBinding
2021/12/29 22:31:34 Starting delete for "argocd-server" RoleBinding
2021/12/29 22:31:34 Starting delete for "argocd-dex-server" Role
2021/12/29 22:31:34 Starting delete for "argocd-server" Role
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" Role
2021/12/29 22:31:34 Starting delete for "argocd-server" ClusterRoleBinding
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" ClusterRoleBinding
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" ClusterRole
2021/12/29 22:31:34 Starting delete for "argocd-server" ClusterRole
2021/12/29 22:31:34 Starting delete for "argocd-tls-certs-cm" ConfigMap
2021/12/29 22:31:34 Starting delete for "argocd-cm" ConfigMap
2021/12/29 22:31:34 Starting delete for "argocd-gpg-keys-cm" ConfigMap
2021/12/29 22:31:34 Starting delete for "argocd-rbac-cm" ConfigMap
2021/12/29 22:31:34 Starting delete for "argocd-ssh-known-hosts-cm" ConfigMap
2021/12/29 22:31:34 Starting delete for "argocd-secret" Secret
2021/12/29 22:31:34 Starting delete for "argocd-dex-server" ServiceAccount
2021/12/29 22:31:34 Starting delete for "argocd-application-controller" ServiceAccount
2021/12/29 22:31:34 Starting delete for "argocd-server" ServiceAccount
2021/12/29 22:31:34 purge requested for argocd
2021/12/29 22:31:34 release uninstalled, response: &{0x1400093c000 }
2021/12/29 22:31:34 === all plugins' Install/Uninstall/Reinstall process are succeeded ===
2021/12/29 22:31:34 === END ===
 ~/MyGolangProjects/stream/demo   main  kgpo
NAME                     READY   STATUS    RESTARTS   AGE
hello-75f9fddff6-l6kjj   1/1     Running   0          6h19m

/kind bug

proposal: add a progress bar to the process of downloading the plugin

Description

add a progress bar to the process of downloading the plugin

Describe the Proposal

Describe the Alternatives You Have Considered

// TODO

/kind proposal
/assign @daniel-hutao I'm very interested in this feature.

proposal: print some logs when `dtm init -f xxx.yaml` with no error

Description

print some logs when dtm init -f xxx.yaml with no error

need progress bar when downloading plugins

Description

What are you trying to do, , how do you want to do it, how would you do it differently?

Is it something you currently cannot do? Is this related to an issue?

Describe the Proposal

A clear and concise description of what you would like.

Has the Feature been Requested Before?

Please link related issues here, if any.

Describe the Alternatives You Have Considered

A clear and concise description of any alternative solution or feature you've considered.

Additional Context

Add any other helpful context or screenshots about the feature request here.

put the actual action into the errors log

see the discussion below for more information.

https://github.com/merico-dev/stream/pull/46#discussion_r773565726_

proposal: make the makefile aware of version changes

Describe the Proposal

Make the makefile aware of version changes.

The version at the Makefile now is Hardcored:

// ...
build: fmt vet ## Build dtm & plugins locally.
	go mod tidy
	go build -buildmode=plugin -trimpath -gcflags="all=-N -l" -o plugins/githubactions_0.0.1.so ./cmd/githubactions/
	go build -buildmode=plugin -trimpath -gcflags="all=-N -l" -o plugins/argocd_0.0.1.so ./cmd/argocd/
	go build -buildmode=plugin -trimpath -gcflags="all=-N -l" -o plugins/argocdapp_0.0.1.so ./cmd/argocdapp/
	go build -trimpath -gcflags="all=-N -l" -o dtm ./cmd/devstream/
// ...

Describe the Alternatives You Have Considered

1. Config the version as a variable at Makefile.
2. Use sed command in the first line at the build stage(make build) to render this variable into the version.go file.
3. So both Golang code & Makefile will know the real version and it could be configured with the single entrance - Makefile
4. Like: export version=0.0.1 & make build (Makefile reads the env variable)

/cc @merico-dev/devstream Do you think this idea is suitable?

DevStream Core: state management

Description

A local state file as the first implementation.

Remembering which plugins are already executed, which are not, which are executed but failed.

When re-run, only execute those failed/not executed ones.

🍀 `Proposal`: Adding support for CN users

Description

For users behind the GFW without a VPN, it's not possible to build or run using the default/official registry sources for Docker images, go modules, helm charts, and so on.

Describe the Proposal

Add documentation about how to set:

• GOPROXY (for example, goproxy.cn)
• Docker registry mirrors (e.g., 官方**区 or 阿里云等源)
• helm registry mirrors (e.g., 阿里源等其他源)

so that users behind the GFW can work and use DevStream without any problem.

Extra CLI params might be needed.

Any change should not affect the current default behavior for non-GFW-blocked users.

Related to #36 which also needs to be implemented.

GitHub Actions plugin: update the workflows for Golang

Description

Currently, the github actions plugin will create two workflows for Golang, one is for pull request, the other is for the master/main branch.

Maybe we can simplify it, only create one workflow, for example, like this one:

https://github.com/actions/starter-workflows/blob/a85155b04a1b885de7a5021312303fe5c1cb58e4/ci/go.yml

Cross-platform build support

Description

As it's been discussed at https://github.com/merico-dev/stream/pull/20#discussion_r757267479, we need to support cross-platform build, but it's not very urgent.

We could support linux-amd64 darwin-amd64 windowns-amd64 first, then support other arch like "arm i386, mips64le, ppc64le, s390x ...

see also https://github.com/merico-dev/stream/pull/20

Bug: argocdapp installation failed with no specific error log output

Describe the Bug

argocdapp installation failed with no error log output

How to Reproduce

1. cp examples/config.yaml /tmp/
2. dtm install -f /tmp/config.yaml

Screenshots

Additional Context

2021/12/29 11:22:31 release installed successfully: argocd/argo-cd-3.29.4
2021/12/29 11:22:31 === plugin argocd process done ===
2021/12/29 11:22:31 processing progress: 3/3
2021/12/29 11:22:31 processing: argocdapp -> install
2021/12/29 11:22:32 === plugin argocdapp process failed ===
2021/12/29 11:22:32 === some errors occurred during plugins Install/Uninstall/Reinstall process ===
2021/12/29 11:22:32 exit status 1
2021/12/29 11:22:32 === END ===

/kind bug

Create a new plugin for Jenkins

Description

Maybe it could be the same as the argocd plugin and we can implement a helm install for Jenkins in K8s.

Maybe we could reuse some part of the code (helm install), in which case, a new go module is appreciated.

if only "argocd" and "argocdapp" in config.yaml, "argocdapp" will be triggered twice, while "argocd" won't be triggerd

Describe the Bug

"argocdapp" will be triggered twice:

How to Reproduce

Steps to reproduce the bug:

1. Go to ...
2. Click ...
3. Scroll down to ...
4. See the error ...

Expected Behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain the issue.

Additional Context

Add any other helpful context about the issue here.

bug: invalid memory address or nil pointer dereference at getFileSHA()

Describe the Bug

invalid memory address or nil pointer dereference at getFileSHA()

2021/12/28 13:18:02 language is go-1.17
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x12bbfc7e0]

goroutine 1 [running]:
github.com/merico-dev/stream/internal/pkg/githubactions.(*GithubActions).getFileSHA(0x1400006a7e0, {0x12bc03c3c, 0xe})
	github.com/merico-dev/stream/internal/pkg/githubactions/githubactions.go:125 +0x1a0
github.com/merico-dev/stream/internal/pkg/githubactions.(*GithubActions).DeleteWorkflow(0x1400006a7e0, 0x140001c65d0)
	github.com/merico-dev/stream/internal/pkg/githubactions/githubactions.go:80 +0x60
github.com/merico-dev/stream/internal/pkg/githubactions.Uninstall(0x14000113c10)
	github.com/merico-dev/stream/internal/pkg/githubactions/uninstall.go:17 +0x218
github.com/merico-dev/stream/cmd/githubactions.Plugin.Uninstall({0x0, 0x0}, 0x14000113c10)
	github.com/merico-dev/stream/cmd/githubactions/main.go:27 +0x34
github.com/merico-dev/stream/internal/pkg/pluginengine.Uninstall(0x14000113bf0)
	github.com/merico-dev/stream/internal/pkg/pluginengine/plugin.go:42 +0xd4
github.com/merico-dev/stream/internal/pkg/planmanager.(*Plan).Execute(0x14000113b60)
	github.com/merico-dev/stream/internal/pkg/planmanager/plan.go:61 +0x3b0
main.installCMDFunc(0x10348b980, {0x1400006a3e0, 0x0, 0x2})
	github.com/merico-dev/stream/cmd/devstream/install.go:45 +0x318
github.com/spf13/cobra.(*Command).execute(0x10348b980, {0x1400006a3c0, 0x2, 0x2})
	github.com/spf13/[email protected]/command.go:860 +0xa04
github.com/spf13/cobra.(*Command).ExecuteC(0x10348bc00)
	github.com/spf13/[email protected]/command.go:974 +0x7b8
github.com/spf13/cobra.(*Command).Execute(0x10348bc00)
	github.com/spf13/[email protected]/command.go:902 +0x30
main.main()
	github.com/merico-dev/stream/cmd/devstream/main.go:28 +0x30

Other notes

I've fixed this bug at #74 but it's reopen at #76 by "resolve conflict".

This is not a criticism of @lfbdev
Just remind us all that we should pay more attention at "avoid confict"/"resolve conflict"/"code review"

/kind bug
/cc @merico-dev/devstream

0.0.1 release: *.so uploaded

Done-Done Checklist

• delete the current v0.0.1 tag and release
• create a new tag v0.0.1 on the main branch once all tickets in v0.1.0 milestone are finished
• create a release using the new v0.0.1 tag
• upload dtm binary and three so files (build for mac m1 only for now) into the release

proposal: support plugins upgrade

Description

For example, we have installed the v1 version of argocd, and the configuration file is changed to v2 now. Planmanager needs to be able to recognize this change and give a corresponding upgrade plan

Describe the Proposal

Describe the Alternatives You Have Considered

// TODO

/kind proposal

Require Multiple Reviewers for PR

Description

For the main branch, set the number of approving reviews to 2.

GitHub Actions plugin: add support for Python and Nodejs

Description

At the moment, the github actions plugin only can create workflows for Golang. We need to be able to support Python and Nodejs (we use them ourselves, so these two have higher priority than other programming languages).

For Python, maybe we can create some simple workflow like this one:
https://github.com/actions/starter-workflows/blob/a85155b04a1b885de7a5021312303fe5c1cb58e4/ci/python-app.yml
More research in github actions starter workflows is welcome.

For Node, it's a bit more complicated because some use node alone, some use it with webpack, some use it with gulp, etc.
Examples:

• https://github.com/actions/starter-workflows/blob/a85155b04a1b885de7a5021312303fe5c1cb58e4/ci/node.js.yml
• https://github.com/actions/starter-workflows/blob/a85155b04a1b885de7a5021312303fe5c1cb58e4/ci/webpack.yml
• https://github.com/actions/starter-workflows/blob/a85155b04a1b885de7a5021312303fe5c1cb58e4/ci/npm-grunt.yml
  Some more research in this repo might help. We might need to add more parameters to the config to support different options.

proposal: githubactions supports multi-repo

Description

githubactions supports multi-repo

Describe the Proposal