[DT,Dish][UI] As a User, I want to pick the GitRepo WGE is writing to so that I can use the repo structure that maps to my organisation

[davidstauffer]

Background

Organisations want to map their repository structure to match their team and processes. Almost every engagement adopts a different repository structure matching the particular customer (Conway's law).

Currently, DT is adopting WGE for their platform. They will use a single instance of WGE for the platform team and the tenants. Each tenant will use their own repository's.

That use case is a good example why we need to allow the user to select what repository to write a PR from our GUI.

Goal

As a User, I can select the GitRepository WGE is writing to and create the PR so that I can use the repo structure that maps to my organisation

As a User, when creating a PR a sensible default is provided so that it doesn't require additional information to create a PR in the right location

As a Platform team, I can create GitRepository defaults for a specific tenant so that I can provide guidance on where to write

As a Platform team, I can set a specific GitRepository for a tenant so that I can define the guardrails

[davidstauffer]

Coming our way.... @foot @bigkevmcd

[foot]

Sure, I think this is UI work mainly.

Would selecting a repo from the list of GitRepositories that the current user has RBAC access to work for their use case?

Or we could just let them type in any repo..

[bigkevmcd]

I'd opt for selecting a GitRepository, at least you'd know that it would probably be deployed after it was changed

[foot]

• Lets migrate the rest of the gitauth UI code to EE was core doesn't use it at all
  • UI
  • BE
• Leave appcontext in core.
• Untangle gitauth from appcontext

[foot]

To choose a "default" for a tenant / user we could choose the default in the UI via an anno/label.

[foot]

Order repos:

• flux-system/flux-sytem first if it exists to keep it a smooth migration
• Allow users to choose default somehow (howwww?)

@davidstauffer 🍽️

[nab-gha]

Not following this, if this is creating a PR to create a cluster and other resources containing the profiles.yaml, kustomizations yamls and the GitopsCluster object and resources from the template then surely the latter file has to be applied to the management cluster so WGE will process it or are we going to get WGE to monitor other repos too?

[nab-gha]

So maybe we could a repository to the new content/path form of the resourceTemplates so that the template author can define which repo as well as folder/file their resource get's written too? The repository field would reference a GitRepository object that would be defined in the template and be deployed to the Management Cluster much like the idea for profiles in https://github.com/weaveworks/weave-gitops-enterprise/issues/2107#issuecomment-1354594536. Then WGE would generate multiple PRs against different repos?

Alternatively a simpler solution would be to create a PR to add the ./clusters/management/${{ .params.CLUSTER_NAME }}/cluster.yaml file containing the GitopsCluster to the management cluster and as mentioned in Slack allow the user to select another repo for all the other resources?

[bigkevmcd]

Adding the repository starts to add a lot of additional complexity.

It increases the API request time, and involves ensuring that the token is valid across repositories, otherwise the user might need to give us an auth token for each of the repositories.

While I definitely think that multiple repositories are a very desirable element, I worry that we're setting folks up for failure with this, perhaps the approach for writing resources needs to be rethought.

[nab-gha]

Agreed, I think generating more than two PRs (one for GitopsCluster to the management cluster repo and one against the specified target repo for this leaf cluster) is too confusing. However, supporting a separate repo for a leaf cluster makes a lot of sense, some user might not want to define the details of their leaf cluster in the management cluster's repo.

The leaf cluster might be in a separate environment which uses a different SCM provider. An example of this is HSBC who have an on prem GitHub Enterprise they use for application development, IaC development and CI/CD for both against dev and staging clusters but when they move to a GitOps pull model rather than their current Jenkins/push model for the production clusters they will not be able to point flux in the prod clusters at GitHub repos. This is because their SLA for the GitHub Enterprise is business day remediation and the production services have a sub hour remediation SLA. The plan discussed during our pre sales call was to use either S3 or AWS CodeCommit as a source for flux in the management clusters. So when creating a production cluster being able to create a PR against a separate Repo for the leaf clusters resources makes sense.

[nab-gha]

For an update re potential HSBC use case see https://weaveworks.slack.com/archives/C0146C3KA4C/p1671194684054099

[foot]

Lets go with: to declare a GitRepo as the default one, priority:

• annotations: weave.works/repo-rule: default
• name:flux-system, namespace:flux-system
• alphabetical