Closed Racer159 closed 8 months ago
@Racer159 I agree with what you stated above, but Just a thought: for clarity and some renovate grossness with inconsistent image definitions in charts in uds-core we Broke out the components so the common component had a shared values file imported and then the image specific values were in their own values file.
That makes it so the flavor components that import the common both need to pass upstream-values.yaml
and registry1-values.yaml
respectively into each of the flavor components. I think we should continue using this pattern for consistency. In that case item 1 here is actually moot, but would be replaced with align the use of common and flavor specific values in components with other uds packages
This would end up looking like:
Similarly, for the description and i guess this could go either way, I'd suggest we omit the common description and add a specific one on each flavor like: description: "Deploy gitlab with registry1 images"
and description: "Deploy gitlab with upstream images"
Will be completed by https://github.com/defenseunicorns/uds-package-gitlab/pull/29
There are a few things that could be cleaned up about the root
zarf.yaml
in this repo:https://github.com/defenseunicorns/uds-package-gitlab/blob/main/zarf.yaml
architecture
may be fine for your use case but it would prevent an upstream arm package from being made - usingonly.cluster.architecture
only on the registry1 component would limit those effects to that flavor typedescription
can come from the common child package unless you want to override it with something specificrenovate.json
can automatically update charts with something like https://github.com/defenseunicorns/zarf/blob/2319b6f9d5491ed7bac8b63322c030cac1d4ffe9/renovate.json#L47