Philippe Scorsolini

https://github.com/cloudnative-pg/cloudnative-pg/blob/main/config/default/kustomization.yaml is not meant for consumption, it's used to generate the release manifests. We could add an additional layer as you suggest, but would that make any difference for renovate...

I could reproduce the issue. cert-manager-cluster-certificates.yaml ```yaml --- apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: selfsigned-issuer spec: selfSigned: {} --- apiVersion: v1 kind: Secret metadata: name: my-postgres-server-cert labels: cnpg.io/reload: "" ---...

This indeed would allow to configure assuming that a secret with the Client CA is available, e.g.: ```yaml --- apiVersion: v1 kind: Namespace metadata: name: sandbox --- apiVersion: cert-manager.io/v1 kind:...

what about adding a field to the `PackageSpec` and `PackageRevisionSpec`, something like: ```yaml apiVersion: pkg.crossplane.io/v1 kind: Configuration metadata: name: platform-ref-aws spec: package: xpkg.upbound.io/upbound/platform-ref-aws:v0.6.0 dependencies: rewrite: - prefix: "xpkg.upbound.io" newPrefix: "my-awesome-registry.com"...

@pedjak, a package (Provider/Configuration/Functions) usually points to an image which we look into to get the meta information about the package itself, which can then potentially point to a separate...

Related https://github.com/crossplane/crossplane/issues/5032

@lindblombr, what would be the difference w.r.t. manually deploying a NetworkPolicy alongside your Function manifest? Except for when they are declared as dependencies for a Configuration maybe. That said, I...

What would be the usecase @viniciusfs? Could it be covered by the "default data" that can be defined now at the composition level?

/retest

@vladimirvivien, can you trigger the tests? 🙏