Support having app directory in different repo

[noam-codefresh]

We think that having the basic GitOps infrastructure in the GitOps repo (the one with the bootstrap directory, and the argo-cd kustomization file), and the actuals apps in a different repo might be a useful use-case for may users.

Why:

Splitting the responsibility between the two repos (which applications to apply to the cluster, vs. what each application actually contain) will make it easier to handle security. A different set of permissions will be required to just edit a manifest, or add a patch to some app, vs. the permissions required to create a new project, deploy to a new cluster and actually adding a new application.

Suggested structure:

GitOps-repo
├── apps
│   ├── remote-dir-app
│   │   └── project-name
│   │       └── config.json                <─┐        ─┐ // references 2nd-repo//apps/remote-dir-app/project-name
│   ├── remote-kust-app                      │         │
│   │   └── project-name                     │         │
│   │       └── config.json                <─┤        ─┧ // references 2nd-repo//apps/remote-kust-app/overlays/project-name
│   └── local-kust-app                       │         ┃
│       ├── base                      <─┐    │         ┃
│       │   └── kustomization.yaml      │    │         ┃
│       └── overlays                    │    │         ┃
│           └── project-name            │    │  <─┐    ┃
│               ├── config.json         │  <─┤   ─┘    ┃ // references apps/local-kust-app/overlays/project-name (current directory)
│               └── kustomization.yaml ─┘    │         ┃ // references ../../base
├── bootstrap                                │         ┃
│   ├── argo-cd                       <─┐    │         ┃
│   │   └── kustomization.yaml          │    │         ┃
│   ├── argo-cd.yaml                   ─┘    │         ┃ // references bootstrap/argo-cd
│   └── root.yaml                      ─┐    │         ┃ // references projects
└── projects                          <─┘    │         ┃
    └── project-name.yaml                   ─┘         ┃ // references apps/**/project-name/config.json
                                                       ┃
2nd-repo                                               ┃
└── apps                                               ┃
    ├── remote-dir-app                                 ┃
    │   └── project-name                             <─┦
    │       └── entities-cm.yaml                       │
    └── remote-kust-app                                │
        ├── base                      <─┐              │
        │   └── kustomization.yaml      │              │
        └── overlays                    │              │
            └── project-name            │            <─┘
                ├── kustomization.yaml ─┘                // references ../../base
                └── namespace.yaml

Required changes

The application create command will have another optional flag. Maybe --target-repo? If the user uses it, the code will clone both repos (Gitops + target), commit the config.json at the correct location in the Gitops repo, and the kustomization overlay/<project_name> and base in the matching location in the target repo. In case the user creates a Directory Application, the code will just make sure the correct directory exist in the target repo.

Does it all make sense? Is it a useful use case to have in Autopilot? Are there any more use-cases in that area that we might also want to support, or maybe we are missing anything?

[noam-codefresh]

A different suggestion I thought about - instead of having Autopilot manage two repos (or more) - add an option to app create to make it only create the config.json file in the GitOps repo, which will direct to the --app url value (similar to how Directory Apps are currently implemented). It will be up to the user to make sure this target URL contains its preferred way to manage Kustomize applications (base/overlay, or whatever method they prefer).
It makes Autopilot less opinionated, which isn't necessarily a good thing, but it might be required for more advanced use cases. It will also help us avoid adding a bunch of optional flags to app create just to support 2 repos.