Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

target helm chart directory should be configurable #4320

Open
bavarianbidi opened this issue Nov 11, 2024 · 1 comment
Open

target helm chart directory should be configurable #4320

bavarianbidi opened this issue Nov 11, 2024 · 1 comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@bavarianbidi
Copy link
Contributor

What do you want to happen?

I gave the very early helm.kubebuilder.io/v1-alpha plugin a try.

One downside with the generated manifests is the current chosen file path for the helm charts.
All the content of the generated helm charts goes to ./dist folder on.
(xref: relevant code places).

I very often use goreleaser for the release process.
And per default, all the generated build artifacts will be placed under the ./dist folder. As these generated artifacts should not get tracked by git, we ignore the entire ./dist folder in our .gitignore file.

Per documentation, it's possible in goreleaser to change that location (xref: goreleaser doc).
But as i do not prefer to change locations from an existing integrated tool, just because of integrating a new tool i would like to see to make the target folder configurable 🙏

I can take over the implementation if wanted

Extra Labels

No response

@bavarianbidi bavarianbidi added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 11, 2024
@camilamacedo86
Copy link
Member

Hi @bavarianbidi,

We use the dist directory to add the bundle done with YAML via Kustomize to allow people to distribute their solutions easily; see:

.PHONY: build-installer
build-installer: manifests generate kustomize ## Generate a consolidated YAML with CRDs and deployment.
mkdir -p dist
cd config/manager && $(KUSTOMIZE) edit set image controller=${IMG}
$(KUSTOMIZE) build config/default > dist/install.yaml

By default, this is the most logical place.

However, if you want to add an OPTIONAL flag to the plugin to allow people to output the chart elsewhere, please go forward with it. It seems like a nice improvement 🚀 .

The flag would need to be added at:
https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/optional/helm/v1alpha/init.go#L34-L42

And here:
https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/optional/helm/v1alpha/edit.go

Then, we need to track this info in the PROJECT file. See how we track all input provided when using the DeployImage plugin:

cfg := PluginConfig{}
if err := p.config.DecodePluginConfig(pluginKey, &cfg); errors.As(err, &config.UnsupportedFieldError{}) {
// Config doesn't support per-plugin configuration, so we can't track them
} else {
// Fail unless they key wasn't found, which just means it is the first resource tracked
if err != nil && !errors.As(err, &config.PluginKeyNotFoundError{}) {
return err
}
configDataOptions := options{
Image: p.image,
ContainerCommand: p.imageContainerCommand,
ContainerPort: p.imageContainerPort,
RunAsUser: p.runAsUser,
}
cfg.Resources = append(cfg.Resources, ResourceData{
Group: p.resource.GVK.Group,
Domain: p.resource.GVK.Domain,
Version: p.resource.GVK.Version,
Kind: p.resource.GVK.Kind,
Options: configDataOptions,
},
)
if err := p.config.EncodePluginConfig(pluginKey, cfg); err != nil {
return err
}
}

See how this results in the PROJECT file:
https://github.com/kubernetes-sigs/kubebuilder/blob/master/testdata/project-v4-with-plugins/PROJECT#L8-L25

Then, we would also need to add a condition to retrieve this value when present for the command alpha generate:

https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/cli/alpha/internal/generate.go#L404-L411

Similar to what we do for the deploy image here:

func getDeployImageOptions(resource v1alpha1.ResourceData) []string {
var args []string
if resource.Options.Image != "" {
args = append(args, fmt.Sprintf("--image=%s", resource.Options.Image))
}
if resource.Options.ContainerCommand != "" {
args = append(args, fmt.Sprintf("--image-container-command=%s", resource.Options.ContainerCommand))
}
if resource.Options.ContainerPort != "" {
args = append(args, fmt.Sprintf("--image-container-port=%s", resource.Options.ContainerPort))
}
if resource.Options.RunAsUser != "" {
args = append(args, fmt.Sprintf("--run-as-user=%s", resource.Options.RunAsUser))
}
args = append(args, fmt.Sprintf("--plugins=%s", "deploy-image/v1-alpha"))
return args
}

Looking forward to see your PR 🥇

@camilamacedo86 camilamacedo86 added help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

2 participants