Alexander Block

@MarkCupitt Yes this sounds like it could work. Regarding the 1Mb limitations: You could also consider letting your job clone the Git Repo that contains the large json. Or use...

I assume, without really knowing 100%, that showing them pre-upgrade/deploy is technically possible, as part of the diff step that happens before the deploy. However, if it comes to stuff...

`clusterSecret` (and clusterConfigMap) expects a valid yaml file as content of the referenced key. Check the docs here: https://kluctl.io/docs/kluctl/reference/templating/variable-sources/#clusterconfigmap I your case, the secret contains keys with plain secret values,...

I'm not sure that what you try is possible at all. Even if it would, it would be extremely unreliable. You're using an `ObjectTemplate` to transform a secret and then...

The `key` in `clusterSecret` refers to a key in the `data` part of the secret. Your use of clusterSecret would require this secret: ```yaml apiVersion: v1 kind: Secret metadata: name:...

A future version on Kluctl will support the way you tried to load the secret: #351 This will however not solve the other issues.

I'm trying to understand your initial requirement here. What do you mean with "additional" processing?

The way I understand you is that you want to have a shared kustimization with a set of shared variables attached to it, all while NOT having the kustomization below...

Based on what I wrote before: Right now, it is not explicitly forbidden to mix deployment-items and sub-deployments, it simply fails at some point. This should also be re-considered.

@senbax-admin Sorry for the late response, I somehow missed this issue. Is this still relevant? Generally, all git included sub-deployment inherit the templating context from the parent, meaning that all...