GithubHelp home page GithubHelp logo

mittwald / go-helm-client Goto Github PK

View Code? Open in Web Editor NEW
230.0 7.0 102.0 394 KB

Go client for accessing the Helm package manager

License: MIT License

Go 96.11% Makefile 3.89%
golang golang-library helm kubernetes hacktoberfest

go-helm-client's Introduction

Go Helm Client

Go client library for accessing Helm, enabling the user to programmatically change helm charts and releases.

This library is build upon helm and available under the MIT License.

Compile & Test GitHub license Go Report Card Documentation

Installation

Install this library using go get:

$ go get github.com/mittwald/go-helm-client

Usage

Example usage of the client can be found in the package examples.

Private chart repository

When working with private repositories, you can utilize the Username and Password parameters of a chart entry to specify credentials.

An example of this can be found in the corresponding example.

Mock Client

This library includes a mock client mock/interface_mock.go which is generated by mockgen.

Example usage of the mocked client can be found in mock/mock_test.go.

If you made changes to interface.go, you should issue the make generate command to trigger code generation.

Documentation

For more specific documentation, please refer to the godoc of this library.

go-helm-client's People

Contributors

cheerioskun avatar dependabot[bot] avatar dgloeckner avatar elenz97 avatar guitarlum avatar hensur avatar hokadiri avatar izturn avatar jkmw avatar leontappe avatar luisdavim avatar martin-helmich avatar meatballhat avatar mtintes avatar nikolaigut avatar nxtcoder17 avatar ravikondamuru avatar ric03 avatar sebrandon1 avatar semin-lev avatar sethgupton-mastery avatar suikast42 avatar sykim-etri avatar tariq1890 avatar yulin-li avatar zalsader avatar zlangbert avatar zvonkok avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

go-helm-client's Issues

KubeContext in KubeConfClientOptions not working

I had a kubeconfig byte with multiple contexts and current-context in kubeconfig is not what I want to used when build a helm client.

What I expected

  1. Set KubeConfClientOptions.KubeContext to what I want to use.
  2. Build client by NewClientFromKubeConf.
  3. All operation execute by the client should use the context set in step1

What actually happen

All operation execute by the client should still use the original context in kubeconfig

What I do to workaroud

  1. Load kubeconfig to api.Config and set CurrentContext to what I want.
  2. Load api.Config to rest.Config
  3. Build client by NewClientFromRestConf.

Looks like KubeConfClientOptions.KubeContext do not change the behavior of RESTClientGetter creating any k8s client

OCI registry access causes missing registry client error

Trying to install from OCI registry fails with missing registry client error.

        chartSpec := ChartSpec {
                ReleaseName: "bar",
                Version:     "0.1.1",
                ChartName:   "oci://us-docker.pkg.dev/project-132/foo/bar",
                Namespace:   "default",
                UpgradeCRDs: true,
                Wait:        true,
        }
        rel, err := helmClient.InstallOrUpgradeChart(context.Background(), &chartSpec)
        if err != nil {
                panic(err)
        }
panic: unable to lookup chart "oci://us-docker.pkg.dev/project-132/foo/bar", missing registry client

CRD upgrade fails when new CRDs are added

This issue was introduced in #38.

When a new CRD is added to an already released chart, the upgradeCRDV1 and upgradeCRDV1Beta1 methods will fail, since the NotFound error is not explicitly handled:

go-helm-client/client.go

Lines 636 to 639 in 1d53dff

existingCRDObj, err := cl.ApiextensionsV1().CustomResourceDefinitions().Get(ctx, crdObj.Name, metav1.GetOptions{})
if err != nil {
return err
}

In this case, the new CRD should simply be created.

InstallOrUpgradeChart context deadline exceeded

	_, err = helmClient.InstallOrUpgradeChart(context.Background(), &chartSpec)
	if err != nil {
		fmt.Println("xxxxx", err)
	}

error log

 xxxxx context deadline exceeded

I adjust WithTimeout Invalid

go-helm-client version v0.8.4

helm version 
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.17.3"}

/tmp is not available on non UNIX OSs

The default cache and repository config paths are set in /tmp/* (as in here), a path not available in non-UNIX OSs like Windows.

These paths should be either calculated using os.TempDir (which isn't the cleanest solution, but probably takes the least to implement), or use os.MkdirTemp and just cleanup the directory afterwards.

List via api is extremely slow

Hi. When I use the 'helm list' command it takes about 3 seconds.
When I use the api 'ListDeployedReleases', it take about 19 seconds to get the same information.
Can this be improved somehow?

How to initialize NewClientFromKubeConf on Google Cloud's GKE

I am trying to create a Client using the NewClientFromKubeConf factory but keep getting errors.

If I try to simply pass an empty KubeConfClientOptions I get the following error:

panic: kubeconfig missing

Even though my kubeconfig is located under ~/.kube/config and $KUBECONFIG is set accordingly.

So instead I tried passing the KubeConfig parameter to KubeConfClientOptions:

kubeConfig, err := os.ReadFile(kubeConfigPath)
checkErr(err)

clientOptions := &helmclient.KubeConfClientOptions{
    KubeConfig: kubeConfig,
}

kubeConfig properly contains the kubeconfig file as []byte, but I receive the following error anyway:

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x243b3d6]

With a StackTrace that points to this line:

client, err := helmclient.NewClientFromKubeConf(clientOptions)

Am I misunderstanding something?

GenerateName not handled

Looking at the code for TemplateChart, InstallChart, UpgradeChart or InstallOrUpgradeChart, I do not see any code that handles ReleaseName == "" && GenerateName="true".

Something like this worked for me;


// TemplateChart returns a rendered version of the provided ChartSpec 'spec' by performing a "dry-run" install.
func (c *HelmClient) TemplateChart(spec *ChartSpec) ([]byte, error) {
	client := action.NewInstall(c.ActionConfig)
	mergeInstallOptions(spec, client)

	client.DryRun = true
	client.ReleaseName = spec.ReleaseName
	client.Replace = true // Skip the name check
	client.ClientOnly = true
	client.APIVersions = []string{}
	client.IncludeCRDs = true
          
	// NameAndChart will return first the TemplateName if set,
	// second the ReleaseName if set, and lastly the generatedName
	releaseName, _, err := client.NameAndChart([]string{spec.ChartName})
	if err != nil {
		return nil, err
	}
	client.ReleaseName = releaseNameif name, _, err := client.NameAndChart([]string{spec.ChartName}); err == nil {
	

RepositoryConfig issue

hi,

settings.RepositoryConfig = defaultRepositoryConfigPath

I have a question about the line above, the RepositoryConfig is always taken from defaultRepositoryConfigPath although if provide other value inside option, how I can override the default configuration?

settings.KubeContext = options.KubeContext

the second issue about kube context? is it supported? it seems the settings is populated but nothing do with this context

thanks a lot

Breaking changes, upgrading from 0.5.0 -> 0.7.0

Hey,

after upgrading to the new version 0.7.0, my existing project did not work anymore.
This was related to a bug introduced in helm 3.6.1 and fixed in version 3.6.1.

The security fix released in v3.6.1 caused a bug to surface that was previously only an issue in uncommon situations. v3.6.2 provides a solution to this bug

https://github.com/helm/helm/releases/tag/v3.6.2

Upgrading to the newest patch might save others some time ๐Ÿ‘

Clarify Overwriting Chart Values

I was trying to figure out how to overwrite default values from the chart repository. I have to apply dynamic values as we plan on using go-helm-client as part of a self service solution.

Looking at the interfaces, I assume I can pass a string representing the overwritten chart values to the ChartSpec:
chartSpec.ValuesYaml = "..."
Is this assumption correct and if so, how does this string have to be formatted?
Also, do these values overwrite the default values and are the remaining default values retained?

Thank you and best regards

Fetching a chart's tarball does not seem to be supported.

Looking through the API I was unable to find a function allowing me to fetch a chart's tarball.
(helm pull equivalent)
The chart should be specified by name and version, or maybe a ChartSpec.
Note: I am not looking at getting the tarball from a release.

Is it possible to get such a function ?

Alternatively, where should I look in the lower-level helm packages to assemble it myself ?

Add WaitForJob to ChartSpec

Right now, the client only waits for template resources but not for hooks aka Jobs. Would be nice if we could add WaitForJobs to the ChartSpec along with Wait and Timeout

No output for ListDeployedReleases when picking context and namespace.

I have multiple kub clusters that I want to run helm commands on, for unique namespaces. This would helm --kube-context=x --namespace=y in the helm CLI.

The only way I can think to do this is like the following where the function loadDefaultConfig loads my .kube/config file.

	cfg, err := h.loadDefaultConfig()
	if err != nil {
		return nil, fmt.Errorf("unable to load default kubectl config: %w", err)
	}
	client, err := helmclient.NewClientFromKubeConf(&helmclient.KubeConfClientOptions{
		KubeContext: cluster,
		Options: &helmclient.Options{
			Namespace: namespace,
		},
		KubeConfig: cfg,
	})
	if err != nil {
		return nil, fmt.Errorf("unable to make client for %s/%s: %w", cluster, namespace, err)
	}
	a, b := client.ListDeployedReleases()
	fmt.Println("releases are ", a, b, len(a))

Unfortunatly, when I run ListDeployedReleases on the returned object, I see two empty returns. But if I run helm cli with the equivalent parameters, I see results.

Go dependecies error

After importing github.com/mittwald/go-helm-client * v0.8.4 * module, Getting below error
# k8s.io/cli-runtime/pkg/resource ../../../../.go/pkg/mod/k8s.io/[email protected]/pkg/resource/metadata_decoder.go:27:33: undefined: "k8s.io/apimachinery/pkg/runtime/serializer/json".CaseSensitiveJSONIterator

# k8s.io/cli-runtime/pkg/resource
../../../../.go/pkg/mod/k8s.io/[email protected]/pkg/resource/metadata_decoder.go:27:33: undefined: "k8s.io/apimachinery/pkg/runtime/serializer/json".CaseSensitiveJSONIterator`

Memory leak in InstallOrUpgradeChart method

Repeatedly calling the client method InstallOrUpgradeChart() (on whatever chart resource) will result in an increase of used memory.

The behaviour can be reproduced using the below example (which installs/upgrades a goharbor instance):

func main() {
	fmt.Println(os.Getpid()) // Pid used to observe information from /proc/[pid]/status

	ctx := context.Background()

	k, err := ioutil.ReadFile("/path/to/kubeconf")
	if err != nil {
		panic(err)
	}

	cl, _ := helmclient.NewClientFromKubeConf(&helmclient.KubeConfClientOptions{
		Options:     &helmclient.Options{Debug: true, Namespace: "test"},
		KubeContext: "kind",
		KubeConfig:  k,
	})

	cl.AddOrUpdateChartRepo(repo.Entry{
		Name:                  "harbor",
		URL:                   "https://helm.goharbor.io",
		PassCredentialsAll:    true,
	})

	chart := &helmclient.ChartSpec{
		ReleaseName: "test",
		ChartName:   "harbor/harbor",
		Namespace:   "test",
		Version:     "1.7.3",
		Timeout:     5 * time.Second,
		MaxHistory:  1,
	}

	for i := 0; i < 1000; i++ {
		_, err := cl.InstallOrUpgradeChart(ctx, chart)
		if err != nil {
			panic(err)
		}

	}
}

Observing the VmRSS output from /proc/[pid]/status shows a quick memory usage increase (watch grep VmRSS /proc/[pid]/status)

Following the program's calls, one quick assumption was that the newly introduced channels in helm's pkg/action/upgrade.go lack a close() call. Adding the missing calls and retrying it with a patched helm version did not confirm this however.

This issue needs further investigation, as it is unclear wether the actual bug is contained in go-helm-client or in helm itself.

templateChart: nil pointer dereference to Manager.out when performing dependency update

Problem

When trying to execute helmclient.TemplateChart with DependencyUpdate=true the following error is thrown:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x555305]

goroutine 1 [running]:
fmt.Fprintln({0x0, 0x0}, {0xc002317258, 0x1, 0x1})
        C:/Program Files/Go-1.18/src/fmt/print.go:265 +0xa5
helm.sh/helm/v3/pkg/downloader.(*Manager).UpdateRepositories(0xc00221d5f0)
        C:/Users/StrunskyyIllya/go/pkg/mod/helm.sh/helm/[email protected]/pkg/downloader
/manager.go:653 +0x1a9
helm.sh/helm/v3/pkg/downloader.(*Manager).Update(0xc00221d5f0)
        C:/Users/StrunskyyIllya/go/pkg/mod/helm.sh/helm/[email protected]/pkg/downloader
/manager.go:188 +0x293
github.com/mittwald/go-helm-client.(*HelmClient).TemplateChart(0xc0007a0730, 0xc
0003c9ae0)
        C:/Users/StrunskyyIllya/go/pkg/mod/github.com/mittwald/go-helm-client@v0
.9.1/client.go:520 +0xb59
rcloud/rcli/cmd.glob..func1(0x39af980, {0xc0000bb880, 0x0, 0x4})
        C:/Users/StrunskyyIllya/git/r-cloud/deployment/scripts/go/rcloud/cmd/ins
tall.go:84 +0x4f8
github.com/spf13/cobra.(*Command).execute(0x39af980, {0xc0000bb800, 0x4, 0x4})
        C:/Users/StrunskyyIllya/go/pkg/mod/github.com/spf13/[email protected]/command
.go:860 +0xb67
github.com/spf13/cobra.(*Command).ExecuteC(0x39afc00)
        C:/Users/StrunskyyIllya/go/pkg/mod/github.com/spf13/[email protected]/command
.go:974 +0x8b3
github.com/spf13/cobra.(*Command).Execute(0x39afc00)
        C:/Users/StrunskyyIllya/go/pkg/mod/github.com/spf13/[email protected]/command
.go:902 +0x2f
rcloud/rcli/cmd.Execute()
        C:/Users/StrunskyyIllya/git/r-cloud/deployment/scripts/go/rcloud/cmd/roo
t.go:32 +0x25
main.main()
        C:/Users/StrunskyyIllya/git/r-cloud/deployment/scripts/go/rcloud/main.go
:9 +0x17

Cause and Fix

Root cause seems to be the same as in #64.

There was a fix provided in #68, but it looks like at least this place was missed.
It looks like there are currently a few problems with the download of dependencies that relate in one way or another to this issue.
It makes sense to unify dependencyUpdate and the refresh of helmCharts into one single place in my opinon, because the same functionality is used in #78 and potentially later in #79.

Delete Release by ChartName

The API currently provides a method to uninstall installed releases by providing a ChartSpec that has to be identical to the one the release was installed with. Keeping Track of this ChartSpec is complicated, especially if it is partially updated at some point. I am currently looking for a way to uninstall the release based on only the chart name and can see two possibilities:

  1. Provide public Delete method with only a ChartName parameter
  2. Provide public method to generate a ChartSpec from a Release, which can then be passed to Uninstall

Is there already a viable route to achieve this?
Number one would make a lot of sense, as it is close to what the helm CLI does.
Number two is non-trivial without understanding the exact workings of Release & ChartSpec under the hood.

Thank you & best regards
masus04

Support helm chart dependencies

go-helm-client are great to use ! but it does not seem to support helm's dependencies. When charts has dependencies, deployment errors will occur, my chart.yaml like:

# ......
version: 0.1.0
appVersion: 0.1.2
dependencies:
- name: zookeeper-operator
  version: 0.2.8
  repository: https://charts.pravega.io
- name: hostpath-provisioner
  version: 0.5.1
  repository: http://iomesh.com/charts
# ......

Can this client be used to list charts stored in a repository

It looks like this library abstracts only the ability to update a chart, perhaps validate a chart is correctly written (i.e. the linter) and store a new chart to the repository. Is this the case? Is there a way that I can a list of charts from a repository using this library? Similar to helm search repo?

Upgrade: Dependency Update is not implemented at all

On upgrade upgradeOptions.DependencyUpdate is not set from the chartSpec and no dependencyupdate is implemented for upgrade.

My troubleshooting in client.go:

  • In the func 'upgrade(ctx context.Context, spec *ChartSpec)': there is only a check validating that all dependencies are there, but the flag upgradeOptions.DependencyUpdate is never set or read.

I see no harm in adding the dependencyUpdate in upgrade analogous to the install command.

Relates to #78

Pass values to template action in addition yaml file

Hi! I have a brief question. Are there some way to pass additional values to template action? i.e : I want to replicate command helm template <my-template> . --set value="myvalue".

If you use function func (helmclient.Client).TemplateChart(spec *helmclient.ChartSpec) , Type *helmclient.ChartSpec doesn't include something as "values", It only include ValuesYaml.

Namespace "" is invalid: metadata.name: Required value: name or generateName is required

_, err := client.InstallOrUpgradeChart(ctx, &helmclient.ChartSpec{
    ReleaseName:     chart.releaseName,
    Namespace:       "",
    Version:         chart.version,
    ChartName:       chart.chartName,
    CreateNamespace: true,
})

Passing an empty Namespace with CreateNamespace causes InstallOrUpgradeChart to fail with:

Namespace "" is invalid: metadata.name: Required value: name or generateName is required

Install: Dependency Update does not install downloaded charts

On install with installoptions.DependencyUpdate=true there is a bug that causes the downloaded dependencies not to be installed.

My troubleshooting in client.go:

  • In the func 'install(ctx context.Context, spec *ChartSpec)': The helmChart is loaded before the dependency update, which loads chart.dependencies initially to the locally available charts.
  • After downloader.Manager.Update() is called the charts are downloaded, but the dependencies are not updated in the helmChart
  • A quick test to reload the helm chart calling c.getChart again solves the problem.

Error: "cannot re-use a name that is still in use"

I'm using

_, err := client.InstallOrUpgradeChart(ctx, &helmclient.ChartSpec{
    ReleaseName:     chart.releaseName,
    Namespace:       chart.namespace,
    Version:         chart.version,
    ChartName:       chart.chartName,
})

to install or upgrade a chart to a new version, but am getting this error: "cannot re-use a name that is still in use"

I thought this function would upgrade the chart if the release already exists. Is there some other function or parameter that I should be using to make it upgrade if there's a newer version and the release already exists?

Is upgrading a release installed from local chart files supported?

I am trying to upgrade some values in a helm release installed before by this command: helm upgrade -i --create-namespace -n foo barRelease ./chart

I tried UpgradeChart method in this package, but it seems that a chart name like repo/chart which represents a chart in some repo has to be provided.
I read some code of this method and find it invoked GetChart method indeed.

So I wonder If I am using this package the right way and if this package supports my case of upgrading release values of local charts?

Use HELM_REPOSITORY_CONFIG env

Is it possible for the helm client to use HELM_REPOSITORY_CONFIG?

My use case is I am building a small tool that is upgrading existing releases, and currently in order to do so I need to use AddOrUpdateChartRepo however I already have all these charts added locally (running helm repo add ...).

Options.Namespace takes priority over ChartSpec.Namespace

My use case:
I have initialized a helm client, and I'm iterating through multiple charts and installing them one by one. Different charts go to different namespaces.

I've initialized the helm client like this:

        opt := &helmclient.KubeConfClientOptions{
            Options: &helmclient.Options{
                Namespace:        "default",
                RepositoryCache:  "/tmp/.helmcache",
                RepositoryConfig: "/tmp/.helmrepo",
                Debug:            true,
                Linting:          true,
                DebugLog: func(format string, v ...interface{}) {
                    fmt.Printf(format, v...)
                    fmt.Printf("\n")
                },
            },
            KubeContext: kubecontext,
            KubeConfig: kubeconfig,
        }

        // initialize helm client with the correct kube context
        helmClient, err := helmclient.NewClientFromKubeConf(opt, helmclient.Burst(100), helmclient.Timeout(time.Duration(time.Minute*15)))
        if err != nil {
            return err
        }

and my ChartSpec looks like:

    chartSpec := helmclient.ChartSpec{
        ReleaseName: m.Name,
        ChartName: m.HelmPackage,
        Version: "0.1.0",
        ValuesYaml: string(buf),
        DryRun: m.dryRun,
        Wait: false,
        Timeout: time.Duration(time.Minute*15),
        Namespace: m.Namespace,
        CreateNamespace: true
    }

I've set the ChartSpec.Namespace = "nopeus" and ChartSpec.CreateNamespace = true accordingly and ran InstallOrUpgradeChart with the chart.

Yet when I run this, the charts are deployed to the default namespace instead of the intended nopeus namespace. Which isn't a behavior I would expect.

I would love your help on this. Am I missing something? Is it a bug? Should I just create a new client every time (sounds weird)?

go get fails because of gnostic openapiv2 repo

when trying to run go get github.com/mittwald/go-helm-client the following error occurs

../../go/pkg/mod/k8s.io/[email protected]/pkg/util/openapi/openapi.go:49:37: cannot use doc (type *"github.com/googleapis/gnostic/openapiv2".Document) as type *"github.com/google/gnostic/openapiv2".Document in argument to "k8s.io/kube-openapi/pkg/util/proto".NewOpenAPIData

https://github.com/kubernetes/client-go has/had the same issue kubernetes/client-go#1075. Seems to have something to do with google changing paths from https://github.com/googleapis/gnostic to https://github.com/google/gnostic

Error running example using https://kubernetes-charts.storage.googleapis.com

Getting this error running https://github.com/mittwald/go-helm-client/blob/master/client_test.go#L72-L83

panic: failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden

Getting the same error on cmdline

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com
Error: repo "https://kubernetes-charts.storage.googleapis.com" is no longer available; try "https://charts.helm.sh/stable" instead

can not install

go 1.17- pls help
go get github.com/mittwald/go-helm-client
package oras.land/oras-go/pkg/auth: unrecognized import path "oras.land/oras-go/pkg/auth": reading https://oras.land/oras-go/pkg/auth?go-get=1: 404 Not Found
package oras.land/oras-go/pkg/auth/docker: unrecognized import path "oras.land/oras-go/pkg/auth/docker": reading https://oras.land/oras-go/pkg/auth/docker?go-get=1: 404 Not Found
package oras.land/oras-go/pkg/content: unrecognized import path "oras.land/oras-go/pkg/content": reading https://oras.land/oras-go/pkg/content?go-get=1: 404 Not Found
package oras.land/oras-go/pkg/context: unrecognized import path "oras.land/oras-go/pkg/context": reading https://oras.land/oras-go/pkg/context?go-get=1: 404 Not Found
package oras.land/oras-go/pkg/oras: unrecognized import path "oras.land/oras-go/pkg/oras": reading https://oras.land/oras-go/pkg/oras?go-get=1: 404 Not Found

Support further installation methods besides Helm Repositories

According to the official docs, the following methods exist:

  • A chart repository (as we've seen above)
  • A local chart archive (helm install foo foo-0.1.1.tgz)
  • An unpacked chart directory (helm install foo path/to/foo)
  • A full URL (helm install foo https://example.com/charts/foo-1.2.3.tgz)

I'm specifically interested in the 2 "local" variants mentioned above.

Looking at the implementation of InstallOrUpgradeChart, install and update in client.go we could provide a variant which accepts a local chart directory.

I can try to make contributions if there's a chance that this gets merged ;)

History of releases

Currently as I can see we can't retrieve history for a release.

Do you have any plan to implement this?

It would be useful to fetch history, especially previous revision numbers.

Thanks

Accept target version in `Rollback`

The helm internal method for running the rollback
https://github.com/helm/helm/blob/bed23120b048977d67c929cec915e1d6e0887c5d/pkg/action/rollback.go#L58

takes into account the version from the struct
https://github.com/helm/helm/blob/bed23120b048977d67c929cec915e1d6e0887c5d/pkg/action/rollback.go#L108

which through the helm cli is getting injected at almost top level, when running the command
https://github.com/helm/helm/blob/bed23120b048977d67c929cec915e1d6e0887c5d/cmd/helm/rollback.go#L66

Currently, I did not find a way to modify this value to have a rollback to a particular version. I found that we can overcome this easily by adding the version as a parameter in rollbackRelease.

If there's no alternative way, and you like my proposal, I can work on the fix :D

Other questions that arise are how should the other fields get set? Currently they get inherited from creation, and the helm CLI does something similar.

Support Retrieving installed Charts

There currently does not seem to be any way to retrieve installed charts and their respective values.
There is a method called chartIsInstalled, which checks if a chart is currently installed, but it is private.

Is there currently a way to retrieve information about installed charts using the public interface? If not, is it possible to extend it to support those use cases?

nil pointer dereference to Manager.out when performing dependency update

Problem

I am trying to deploy a chart with external dependencies defined in its chart.yaml. When setting DependencyUpdate: true in the chart spec, the following nil pointer error occurs:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xdb8f74]

goroutine 111 [running]:
fmt.Fprintln({0x0, 0x0}, {0xc009729ad8, 0x1, 0x1})
        /usr/local/go/src/fmt/print.go:265 +0x54
helm.sh/helm/v3/pkg/downloader.(*Manager).UpdateRepositories(0xc0037166c0)
        /go/pkg/mod/helm.sh/helm/[email protected]/pkg/downloader/manager.go:653 +0x96
helm.sh/helm/v3/pkg/downloader.(*Manager).Update(0xc0037166c0)
        /go/pkg/mod/helm.sh/helm/[email protected]/pkg/downloader/manager.go:188 +0xb4
github.com/mittwald/go-helm-client.(*HelmClient).install(0xc001ab3140, {0x28251f8, 0xc0000580a0}, 0xc002a10140)
        /go/pkg/mod/github.com/mittwald/[email protected]/client.go:293 +0x4ad
github.com/mittwald/go-helm-client.(*HelmClient).InstallOrUpgradeChart(0x259e5e3, {0x28251f8, 0xc0000580a0}, 0xc001a925d0)
        /go/pkg/mod/github.com/mittwald/[email protected]/client.go:206 +0x7a

Context

go.mod requirements:

require (
	github.com/mittwald/go-helm-client v0.9.0
	gopkg.in/yaml.v2 v2.4.0
	helm.sh/helm/v3 v3.8.0
	k8s.io/client-go v0.23.1
)

The deployed chart is the official gitea helm chart, which has several references to the bitnami repository.

Cause and a quick fix

The cause of this error seems to be the initialzation of downloader.Manager in client.go:285, where Out is not set. Manager.Out is used in the standard Helm package for writing simple output when checking for dependencies. I circumvented the issue by declaring a bytes.Buffer variable and setting Manager.Out to it, though I suspect one would want an implementation-specific io.writer in that case.

acr helm pull

hi guys,

im trying to install a chart from acr.
When execute repo add and update it works well but when to go to try install a chart gives 401

err = helmClient.AddOrUpdateChartRepo(chartRepo); err != nil { // it works
	    panic(err)
    }

err = helmClient.UpdateChartRepos() // it works
if err != nil {
	return err
}

// Define the chart to be installed
chartSpec := helmclient.ChartSpec{
	ReleaseName: deploy.ReleaseName,
	ChartName:   fmt.Sprintf("%s/%s", deploy.InfoRegistry.RepositoryName, deploy.ChartName),
	Namespace:   "default",
	UpgradeCRDs: false,
	Wait:        true,
	Force: true,
}

if _ , err := helmClient.InstallOrUpgradeChart(context.TODO(), &chartSpec); err != nil { // fails
	logrus.Error(err)
	return err
}

thks.
awesome project !!

Support Chart Labels & Annotations

Our Team relies on Labels & Annotations for both documentation and automation. We label & annotate any deployed ressources but are currently not able to annotate Helm Charts directly using go-helm-client.

Since ChartSpec does not support Labels & Annotations, is there an alternative way to add them or can we add this functionality?

options.Debug not actually checked/used

Discovered today that options.Debug is not actually checked and even if it's false (default) a DebugLog func is still setup based on the fact that DebugLog is false so if I don't want DebugLogs I need to pass an empty func instead of leaving things as they are by default.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.