Open mrsimonemms opened 3 months ago
👋 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.
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 .
At the moment, the structure of the templates is
<cloud>-<vcs>
(eg,aws-github
orcivo-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.
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:Pros
Cons
gitops
repo for the user is no longer a fork of thegitops-template
repo~