Built-in support to make components ordering less error prone

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

I don't know what form this feature could take. Obviously the current components design has had a lot of effort put in, so maybe nothing more can be added, in which case feel free to close the issue.

Why is this needed?

First an example:

componentA is used to apply crosscutting concerns to all resources in a build (e.g. add a label, or set runAsNonRoot: true) componentB is used to model the classic optional feature that modifies existing resources (e.g. add a volumemount/configmap to deployment)

Since components are ordered, care must be taken that componentB is applied before componentA to ensure correctness.

a more advanced example

component B now in addition to creating a configmap needs to overrid a default applied to a deployment. It's not possible as is and needs to be split. Naming/explaining this split is difficult.

In the general case:

Depending on the build, there could be many such ordering constraints and phases (not only 'before defaults/after defaults", but maybe "phase1 phase2.. phaseN"), and it's very hard to keep track of them all (which is a huge advantage of resources: that are guaranteed independent !). So currently one has to rely on docs/naming-conventions/read-the-source/trial-and-error to build the correct result.

Note: while every component is ordered, some (most?) components don't actually need a very precise order (mostly when the resources they operate on is fixed, that these resources have already been created, and they target things that are not subsequently modified). but there is nothing to distinguish these components from the difficult ones with ordering constraints.

So the current ordering of components does have the benefits of simplicity of the design, but IMHO trades it for complexity in actually implementing correct builds with them. I wonder if it was ever considered to build more complexity into components and what they can represent to allow to use them more easily.

note: components are already awesome as is, so this is by no means a rejection of components.

Can you accomplish the motivating task without this feature, and if so, how?

according to how and when components must be applied to produce the correct build, at the declaration split them in separate components and reference them in the exact needed order (needs perfect information)

What other solutions have you considered?

see "accomplish the task without this feature"

Anything else we should know?

ideas:

• components are ordered after accumulated build, but unordered to their siblings (with the restriction that they can't overlap anymore ? so that you can implement the same thing as resources and just merge their results) (but then you have to define what "overlap" means: different resources, or different fields in the same resource => it depends on what can be merged safely). And do this for all components, or just for a new special kind of component ?
• allow to defer (until when ? a condition like 'depends_on: anothercomponent' ?) some parts of a component? So that you can still define on component for one feature, but it applies at the correct time in the build when enabled.
• Probably many more possibilites ? Is there a sweet spot where complexity doesn't explode but still allow to build what we need ?

Cheers,

Feature ownership

• I am interested in contributing this feature myself!