PROPOSAL - refactor the templates to be more composable to reduce the amount of repetition

[mrsimonemms]

At the moment, the structure of the templates is <cloud>-<vcs> (eg, aws-github or civo-gitlab). IMO, this means that there will be an awful lot of duplication in these templates. For example, when I did the recent GCP cluster work (#769) it was only for GitHub - the likelihood is that most (if not all) of this will be identical for GitLab.

This is an additional maintenance burden on our small team that we don't need.

├── akamai-github
├── aws-github
...<lots-more>
└── vultr-gitlab

I would advocate for refactoring this repo so that it incorporates a common folder. This would be for each level. My proposed structure will be something like this:

├── common 
│   ├── cloud  # One folder for each cloud provider, eg `aws`, `civo`, `gcp` etc
│   │   ├── aws # Everything in here is copied to every "aws" gitops
│   │   └── <...>
│   ├── template # Everything in here is copied to every gitops
│   └── vcs # One folder for each VCS provider, eg `github`, `gitlab` etc
│       ├── github # Everything in here is copied to every "github" gitops
│       └── <...>
└── template # Each of the folders we currently have
    ├── akamai-github
    ├── aws-github
    ├── <...>
    └── vultr-gitlab

Pros

• Reduce the amount of duplication we have
• Make it easier to rollout updates

Cons

• The gitops repo for the user is no longer a fork of the gitops-template repo
• How would we maintain backwards compatibility?

[dahendel]

👋 I have a PR open here to address this issue. This converts a current hardcoded template value <GITOPS_REPO_URL>, for example, to a go templating variable ${k1 .GitopsRepoURL } and additionally adds CustomTemplateValues which can be used like this. This allows the current templates to be used but also provide additional templating support. It also adds the sprig FuncMap to the templating engine for use in templates.

[DrummyFloyd]

with this PR merge, i think we can leverage a lot more the gitops-template with a bit of logic in it instead of only in kubefirst-api

can be lead to somekind of custom helm rendering dedicated to K1

but will be a huge breaking change .