Open nabuskey opened 10 months ago
There are some issues no matter which approach we adopt unfortunately.
Nevertheless, the big advantage of the current approach where resources deployed are embedded is that an idpbuilder release "validates" the core packages as they are tested even partially.
If now, we allow the user to install their own core packages using a local folder, git repository, ftp server, etc, then we should mention that our idpbuilder tool cannot guarantee in this case that what they will deploy is 100% compatible with the release x.y.z of idpbuiler.
Remark: We should offer nevertheless the option to allow a under to install their own customized gitea and argocd at their own risk at the condition also that we document which are resources are needed, version supported, etc
If the idpbuilder contributors decide to adopt the second approach (= Install the core package manifests with GitOps), then we should in this case continue to embed them (and document where resources could be consulted) to support the offline mode where users don't have access to internet but only to internal git, ftp, etc servers within their company.
Currently, there is no way to customize core packages other than editing the fiels in in-cluster git repositories. Even if you make changes to these files, they are overwritten if you run the idpbuilder again. We need to provide a way to customize these packages from CLI.
Currently we solve the chicken and egg problem by installing ArgoCD and Gitea without GitOps. This means we have two ways to provide this functionality.