Skip to content

Unit test overhaul and handling additional PackagePush and Lint function use cases #70

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

Open
wants to merge 41 commits into
base: main
Choose a base branch
from

Conversation

frizzr
Copy link
Contributor

@frizzr frizzr commented Mar 1, 2025

I added the Chart struct to help with, for example, modifying your test Helm chart(s) dynamically. This was necessary since by supplying the optional PackagePush setVersionTo and setAppVersionTo parameters, it would change the test charts' content and it was just easier to dynamically make those modifications.

Copy link
Member

@chrira chrira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the tests!
I have some errors running dagger -m tests/ call all

./main.go:140:145: unknown field Version in struct literal of type dagger.HelmPackagePushOpts                                                                                                  
./main.go:169:145: unknown field AppVersion in struct literal of type dagger.HelmPackagePushOpts   

You are not having problems?
Sometime I have testing issues because of caching.

@frizzr
Copy link
Contributor Author

frizzr commented Mar 6, 2025

You are not having problems?
Sometime I have testing issues because of caching.

@chrira :

My apologies for those issues.

I am having problems running unit tests in my local environment....in our company we have to use a custom runner for Dagger due to needing to setup certificates for our company proxy.

RIght now we use Dagger v0.14.0 with our customized base image while your unit tests use v0.16. Do you have any general Dagger advice for handling different environments like this?

I know you are working on setting up CI here....would it be possible to get a minimal CI setup going....just enough to at least run the unit tests upon any change? While it is not ideal to go back to 'push and pray,' I may have to. :(

@chrira
Copy link
Member

chrira commented Mar 19, 2025

@frizzr no worries!

Yes, the tests are executed in GitHub.
The module tests should run on your fork. The integration test will not because of missing credentials.

Here is one example on your fork: https://github.com/frizzr/dagger-module-helm/actions/runs/13639799085/job/38126851023

Hope this helps you getting forward.

@frizzr
Copy link
Contributor Author

frizzr commented Apr 22, 2025

Hello @chrira! It has been awhile, but I finally finished a complete rework of the unit tests along with my feature adds. I'm happy to say that it is all safe to execute the tests in parallel and I came up with a way to guarantee each test is completely independent of each other by having a set of Chart structs that represents our testdata charts in tests/testdata.

This struct, when instantiated as part of NewChartSession, will automatically rewrite each testdata chart's Chart.yaml inside the container's context and automatically suffix a random string to the end of the chart name (without changing the host's content.)

With a different set of chart names per test, it guarantees that we can safely perform tests using ttl.sh and all of this implementation is located in tests/charts.go hidden away from the actual unit tests. The unit tests of course have access to what the new chart name is within each test.

This was a LOT of work I know, and I hope it isn't too crazy or too drastic of a change. Still, I think it could solve some things now and into the future, but I'll let you be the judge of that.

If the whole thing is "too much", then I could fall back and move my feature adds across to the other PR and leave the unit tests alone.

Thanks for considering!

@frizzr frizzr requested a review from chrira April 23, 2025 11:02
@chrira
Copy link
Member

chrira commented Apr 23, 2025

@frizzr what a work, thank you!

Unfortunately it breaks our main return logic of the PackagePush method. See comment:
https://github.com/puzzle/dagger-module-helm/blob/main/helm/main.go#L65

As @RetGal mentioned, the test method for this logic on the main branch (helm-package-push-with-existing-chart) fails with your changes.

Changing fmt.Errorf("Debug") back to nil and re-adding the test should fix it.

@frizzr
Copy link
Contributor Author

frizzr commented Apr 28, 2025

@chrira and @RetGal :

These are hopefully the last set of changes!

I added a good bit more logic, including a use case I had to handle immediately for both PackagePush and Lint where we need to login to more than one registry to be able to resolve all dependencies in a chart. The added logic will scan all dependencies in the chart and for PackagePush if any registries differ from the registry specified, it will login to that registry with the already-supplied credentials in --username and --password. This also meant I needed to optionally accept --username and --password for the Lint function (but I obviously didn't need to add registry/repository arguments to Lint.)

Although it sounds limiting to assume that the same set of credentials can login to multiple different registries, this limitation is acceptable to me given we use the same JFrog Artifactory instance for all of our Helm repositories, but we still need to login to each repository in our dependencies. I would think my situation would be fairly common, so I felt the limitation is acceptable in general.

I also changed the fmt.Errorf("Debug") back to nil.

I did have to make a (breaking?) change to the PackagePush function: For things to work properly with non-OCI repositories, I had to add a new parameter for the non-OCI ability to push a Helm chart to a particular subpath in a Helm repository and change the documentation accordingly....so the user will no longer put the subpath in as part of the repository parameter.

The big question I have is....how did my non-OCI unit test ever work? Wouldn't we need to simulate a non-OCI repository to do the test (given that ttl.sh only can do OCI repositories?) For now I have commented out that unit test.

@frizzr frizzr requested a review from RetGal April 28, 2025 11:10
@frizzr frizzr changed the title Alternate version of #69: Same as #69 + unit tests + unit test Chart struct Unit test overhaul and handling additional PackagePush and Lint function use cases Apr 28, 2025
@RetGal
Copy link
Contributor

RetGal commented Apr 29, 2025

@frizzr you're right, the non-OCI test probably never worked.
However, this fact was hidden because curl was not called with the -f (fail) flag. We also have an integration test that is executed in the gh action, but only for OCI - in the absence of a non-OCI registry.

@chrira we should probably always call curl with the fail flag.

@RetGal
Copy link
Contributor

RetGal commented Apr 30, 2025

@frizzr since you are the only person we know who uses this module along with a non-oci registry and we currently have no means to unit test it, i'd propose to merge it, if it works for your real life use case.

@chrira any objections from your side?

Copy link
Member

@chrira chrira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frizzr are you still working on it?
Note when you are finished. Then we will do the final review and merge it.
Thanks for contributing!

@@ -12,18 +12,23 @@ import (
"fmt"
"os"
"strings"
"hash/crc32"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix formatting

Registry string `yaml:"registry"`
Repository string `yaml:"repository"`
Oci bool `yaml:"oci"`
NonOCISubpath string `yaml:"nonOciSubpath"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix alignment (check tabs/spaces)

Registry: registry,
Repository: repository,
Oci: !useNonOciHelmRepo,
NonOCISubpath: nonOciRepoSubpath,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix alignment (check tabs/spaces)

WithWorkdir("/helm")
version, err := c.WithExec([]string{"sh", "-c", "helm show chart . | yq eval '.version' -"}).Stdout(ctx)
c := h.createContainer(directory)
//c := dag.Container().
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove commented code

@@ -197,7 +293,8 @@ func (h *Helm) Test(
args []string,
) (string, error) {
c := h.createContainer(directory)
out, err := c.WithExec([]string{"sh", "-c", fmt.Sprintf("%s %s", "helm-unittest", strings.Join(args, " "))}).Stdout(ctx)
out, err := c.WithExec([]string{"sh", "-c",
fmt.Sprintf("%s %s", "helm-unittest", strings.Join(args, " "))}).Stdout(ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check formatting

WithExec([]string{"sh", "-c", `echo ${REGISTRY_PASSWORD} | helm registry login ${REGISTRY_URL} --username ${REGISTRY_USERNAME} --password-stdin`}).
WithoutSecretVariable("REGISTRY_PASSWORD").
Sync(ctx)
// We assume we are already logged into an OCI registry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is here no login needed?
@RetGal do we have Integration tests for the case that the version exists on the registry?

}

func (h *Helm) hasMissingDependencies(
func (h *Helm) queryChartWithYq(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

@chrira
Copy link
Member

chrira commented May 12, 2025

@frizzr
Please run gofmt -w helm/main.go on your go files. We formatted the code on main.
Then you should be able to rebase your branch with main.
We are still struggling with testing, see #84
Thanks

@frizzr
Copy link
Contributor Author

frizzr commented May 14, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants