Feature: add support for multiple projects in different groups for gitlab

[slimctl]

Currently we can only pass 1 group as an organization, this works great for github but not for gitlab.

In gitlab repositories/projects are under groups, which means if you have repositories across multiple groups it's not possible to add a webhook to those repositories.

Below is an example of the values.yaml with 1 project.

  piper:
    gitProvider:
      name: gitlab
      # Map of organization configurations.
      organization:
        # -- Name of your Git Organization (GitHub) / Workspace (Bitbucket) or Group (Gitlab)
        name: "private/k8s"
      # Map of webhook configurations.
      webhook:
        # -- (Github/Gitlab) Used of orgLevel=false, to configure webhook for each of the repos provided.
        repoList: ["some-repo"]

Some possible solutions below:

1. You could have a repoList with the full path to the repo for example:

      webhook:
        # -- (Github/Gitlab) Used of orgLevel=false, to configure webhook for each of the repos provided.
        repoList: ["private/k8s/some-repo", "private/k8s/some-repo"]

2. You could create another property called groups

  piper:
    gitProvider:
      name: gitlab
      # Map of organization configurations.
      groups: ["private/k8s", "some-other-project"]

3. You could create specific properties based on the git provider.

  piper:
    gitProvider:
      gitlab:
       # Map of organization configurations.
       groups: ["private/k8s", "some-other-project"]
      github:
       organization: "some-organization"
      bitbucket:
       some-prop: "some-value" 

The latter would be the most flexible one.

EDIT: fixed gitlab naming of groups

[definitelyOmri]

@GoshaDo
what do you say about the following:

piper:
  gitProvider:
    name: ""  # github/bitbucket/gitlab | env: GIT_PROVIDER
    token: "GIT_TOKEN"
    organizations:
      - name: "ORG_NAME"
        webhook:
          url: https://NGROK_ADDRESS/piper/webhook
          orgLevel: false
          repoList: ["REPO_NAME"]

Each org will have its own values for- name, orgLevel, repoList, and webhook_url. and you could have multiple organizations.
one problem and one downside with this maybe.
problem is with the git_token, which could be different for each group, in that case we can insert it into the organization tab.
downside is, this will change/drop the support for env vars, as they currently support one group. to fix this problem we can maybe add an env var support like in QScaler (like ValueOrSecret but with ValueOrEnv)

[GoshaDo]

@GoshaDo what do you say about the following:

piper:
  gitProvider:
    name: ""  # github/bitbucket/gitlab | env: GIT_PROVIDER
    token: "GIT_TOKEN"
    organizations:
      - name: "ORG_NAME"
        webhook:
          url: https://NGROK_ADDRESS/piper/webhook
          orgLevel: false
          repoList: ["REPO_NAME"]

Each org will have its own values for- name, orgLevel, repoList, and webhook_url. and you could have multiple organizations. one problem and one downside with this maybe. problem is with the git_token, which could be different for each group, in that case we can insert it into the organization tab. downside is, this will change/drop the support for env vars, as they currently support one group. to fix this problem we can maybe add an env var support like in QScaler (like ValueOrSecret but with ValueOrEnv)

What if we will manage each "git provider" as seperate CRD ?
While in the helm chart we can provide a way to create a list of those CRDs..
That's way we can manage the structure for each git provider differently with the right naming, and consume secrets for each one etc..
WDYT ? @ssliman @Omri2001

[definitelyOmri]

that might be good, but do we have a use-case for multiple different providers at once?

[slimctl]

@GoshaDo I like the idea of a seperate CRD for each gitprovider. That way you have the right naming, because now it's a bit unclear when using piper.