helm : enhance chart generation about jkube HOT 13 CLOSED

Implementation fix includes options to specify both outputDir where all chart files will be generated, and tarballOutputDir where the tar archive will be generated (independent from outputDir)

Both options can be setup within pom.xml configuration or overridden with properties (e.g. jkube.helm.outputDir)

Regarding outputDir behavior, generated charts will be output by default in target/$chartName/, so for each helmType (one of kubernetes or openshift) charts and files will be output in $outputDir/$helmType. As said the value of outputDir can be overridden, but every generated file will always be nested under $outputDir/kubernetes or $outputDir/openshift.

Regarding tarballOutputDir will default to target.

So implementation differs a little with that of FMP, hope this is OK for you. Please if you find something wrong with this or new behavior is of great inconvenience post a reply with your thoughts.

from jkube.

if the folder is present.. just override the files without deleted the content.

Seems fair for this to be the default behavior, as mvn clean should take care of cleaning. I'll modify current behavior

from jkube.

thanks really nice. I just found something last week. If we don't respect the format "\d.\d.\d" like 1.0.0 for the version example : 1.0.0-SNAPSHOT, when you do helm search ... Helm (3.x) is not expecting that and won't show it in the result. But I love the commit you did.. thanks a lot

from jkube.

I agree that's a bug in helm cli. but there is over 900 issues, so I'm not sure if I add one more it will make a difference.

from jkube.

ok, I see your point. I can live with that.

from jkube.

Thanks for your bug report. @manusa is working on fixing helm support. It would be fixed before the next release

from jkube.

related to #102

from jkube.

Hi @survivant

Last Friday we released 1.0.0-alpha-1 with most of the suggested changes.

You can check configuration examples here and updated documentation here (until we have the final release).

Could you please check if the provided solution works for you, or if there's something missing or that you would like to change?

from jkube.

Are you referring to the quickstart? or to some point in the documentation?

We can change the example to always override the version number and provide one using the suggested format. or hard-code the version in the documentation.

In any case, 1.0.0-SNAPSHOT is a valid Semver 2 version number. There's probably an issue in helm cli.

from jkube.

here my tests :

mvn k8s:build generate a artifcat in the root folder : targetquarkus-k8s-hello-1.0.0-SNAPSHOT.jar there is a "/" missing. should be : target/quarkus-k8s-hello-1.0.0-SNAPSHOT.jar

for : ./charts

it generate the charts in

./charts/kubernetes instead

should we add this also in the chart

apiVersion: v1
appVersion: "1.0" // could it be the project version like 1.0.0-SNAPSHOT ?

from jkube.

There's an active issue fabric8io/fabric8-maven-plugin#1516 (will be ported to JKube once FMP gets deprecated > Eclipse JKube 1.0.0 released) where we want to provide support for Helm v3 (or latest)

So the generated yaml, as of now, should be compatible with this spec (https://github.com/helm/helm/blob/release-2.0/docs/charts.md)

Regarding your output issues, I don't understand what's the issue.
I've tried the following config:

<helm>
  <outputDir>./charts</outputDir>
  <tarballOutputDir>./charts</tarballOutputDir>
</helm>

Which generates the following:

If I use this:

<helm>
  <outputDir>./charts</outputDir>
  <tarballOutputDir>./</tarballOutputDir>
</helm>

I get this instead:

Are you running this on windows BTW?

from jkube.

yes I'm in Windows.

there was 2 issues in my comment.

#1- k8s:build generated the jar file in the wrong folder : missing / to get target/quarkus-k8s-hello-1.0.0-SNAPSHOT.jar

and the second was that the output of the charts should be

./charts/*.yaml

instead of ./charts/kubernetes/*.yalm ? I don't see the point of puting the type in that folder. I suppose the folder "kubernetes" is because the type is kubernetes, if I put openshift in pom.xml the output will be

./charts/openshfift/*.yaml

there is no point of using that information. The output will be the same for both of them. maybe if you use the default values, but if you override the value in the pom.xml, you should use that foldr ?

from jkube.

I understand now.

Regarding #1 I've opened #131 which is quite critical.

Regarding #2 This is the expected behavior, because you can generate charts for both clusters <type>kubernetes,openshift</type> (provided that resources exist for both).

So for 99% of the use cases it doesn't make sense to nest the chart files under a kubernetes directory.
But there is still this edge-case where a user will create charts for both clusters thus needs to have charts nested under directories to prevent files to be overwritten.

The only way I see to omit the cluster type subdirectory is to add an extra-flag (e.g. outputDirectoryOmitTypeClassifier defaults to false) but I find it very ugly. Is this something you really need?

from jkube.