-
|
Hey, I did not find the underlying reason for this decision documented, and would like to understand why this is a non-goal? From my perspective it would be unfortunate as it is a workflow that has been very useful! What are the issues that makes it unsuitable to keep? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
This "non-goal" should be read as "we are not planning to include this in the first GA release". I understand the value of the feature itself, and would even like to see it as a "stretch goal", hence fluxcd/source-controller#56. The reason (for me) that it is marked as a non-goal for the GA is that the Helm Operator was developed from a Git perspective which in the end resulted in an insane amount of complexity within the operator because of various tricks we had to pull off. By targeting "native Helm" functionalities first I am hoping to prevent this as the foundation/design is then tailor made for how Helm likes to behave. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, language confusion on my part, sorry about that! But that is reassuring to hear, and sounds like a good reason for not going ahead with it as the first release. |
Beta Was this translation helpful? Give feedback.
-
|
The idea is to make the source-controller capable of producing |
Beta Was this translation helpful? Give feedback.
-
|
Ah, cool! I should go read the proposals :) But then I think my concerns are very well met, thanks for explaining! |
Beta Was this translation helpful? Give feedback.
The idea is to make the source-controller capable of producing
HelmChartartifacts from aGitRepository(as an extension to already implementedHelmRepository->HelmChart). This way the helm-controller only needs to know how to work with a single resource type (HelmChart), which solves the complexity issue.