Each plugin should be allowed to used multiple times / multiple instances

[IronCore864]

Design 1: Multiple Occurrences of Each Plugin

tools:
- name: go-hello-http
  plugin:
    kind: githubactions
    version: 0.0.1
  options:
    owner: ironcore864
    repo: go-hello-http
    language:
      name: go
      version: "1.17"
    branch: master
    build:
      command: make build
    test:
      coverage: true
---
- name: go-my-second-repo
  plugin:
    kind: githubactions
    version: 0.0.1
  options:
    owner: ironcore864
    repo: go-my-second-repo
    language:
      name: go
      version: "1.17"
    branch: main
    build:
      command: make build
    test:
      coverage: true
- name: CD-production
  plugin:
    kind: argocd
    version: 0.0.1
  options:
    argoCDVersion: 2.2.1
    repo:
      name: argo
      url: https://argoproj.github.io/argo-helm
    chart:
      name: argo/argo-cd
      release_name: argocd
      namespace: argocd
      create_namespace: True
- name: argocdapp-1
  plugin:
    kind: argocdapp
    version: 0.0.1
  options:
    app:
      name: hello1
      namespace: argocd
    destination:
      server: https://kubernetes.default.svc
      namespace: default
    source:
      valuefile: values.yaml
      path: charts/go-hello-http
      repoURL: https://github.com/ironcore864/openstream-gitops-test.git
- name: argocdapp-2
  plugin:
    kind: argocdapp
    version: 0.0.1
  options:
    helmChartVersion: 1.2.3
    app:
      name: hello2
      namespace: argocd
    destination:
      server: https://kubernetes.default.svc
      namespace: default
    source:
      valuefile: values.yaml
      path: charts/another-chart
      repoURL: https://github.com/ironcore864/openstream-gitops-test.git

Pros:

• no need to update the plugin code
• minimum change for the core code: only need to change the state, name of the plugin, and how to load it

Cons:

• big change for the config file; redundancy in the config; each plugin occurs multiple times; long config file (which can be improved in the future by splitting it up)
• might need to verify if a name already exists in the config

Design 2: Each Plugin Occurs Only Once but Supports a List as Input

tools:
- name: githubactions
  version: 0.0.1
  options: # 唯一的改动：变成了列表
  - owner: ironcore864
    repo: go-hello-http
    language:
      name: go
      version: "1.17"
    branch: master
    build:
      command: make build
    test:
      coverage: true
  - owner: ironcore864
    repo: my-second-repo
    language:
      name: go
      version: "1.17"
    branch: main
    build:
      command: make build
    test:
      coverage: true
- 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: True
- name: argocdapp
  version: 0.0.1
  options:
    app1-dev:
      name: hello1
      namespace: argocd
      destination:
        server: dev-cluster
        namespace: default
      source:
        valuefile: values.yaml
        path: charts/go-hello-http
        repoURL: https://github.com/ironcore864/openstream-gitops-test.git
    app1-prod:
      name: hello2
      namespace: argocd
      destination:
        server: prod-cluster
        namespace: default
      source:
        valuefile: values.yaml
        path: charts/another-chart
        repoURL: https://github.com/ironcore864/openstream-gitops-test.git

Pros

• not much needs to be changed for the config; clear and non-redundant config; relatively shorter as well
• no need to change core code

Cons

• each tool's config is a bit long and the structure is more complicated
• need to add "options" list into state
• state/config list comparison is a bit complicated; if the options adds or removes an element, it's more complicated for the state to handle
• each plugin's code must be changed to adapt to the options structure change

Conclusion after Internal Discussion

We will go for design No.1.