Fix & unify helm test setup as make rules

[josvazg]

Summary

Fix the helm image setup from Makefile rules, and unify workflow for CI and local usage.

Proof of Work

✅ Local test pass:

...
Ran 1 of 92 Specs in 228.468 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 91 Skipped

coverage: 2.3% of statements
composite coverage: 2.3% of statements

Ginkgo ran 1 suite in 4m4.802207875s
Test Suite Passed
make stop-kind clean e2e label=focus-helm-flex  25.81s user 24.53s system 18% cpu 4:38.27 total

✅ Cloud tests passing for the first time
✅ Selectable tests pass
✅ Selectable e2e2 pass
✅ Gov test pass

Checklist

• Have you signed our CLA?

[roothorp]

LGTM but we should run the e2e tests to make sure it actually runs as expected.

[josvazg]

LGTM but we should run the e2e tests to make sure it actually runs as expected.

They were run, check out the Proof of Work section with the links at the top:

✅ Cloud tests passing for the first time
✅ Selectable tests pass
✅ Selectable e2e2 pass
✅ Gov test pass

All those were manually kicked on this branch, and to test this branch.

Note the reason I run those separately and manually is because otherwise some changes will not be seen in the CI until this PR is merged. This is because how our PRs use the pull-request-target event to enable external contributions easily. Such event runs CI code from main instead of the branch.

[helderjs]

Only one concern. You removed the action that manages Kind installation and configuration.
The make target run-kind (that calls the script create_kind_cluster.sh) only handle configuration of the Kind cluster.
It works only because the runner (ubuntu-latest) has it pre-installed, however, we have no control on the version we are running.
I'd ad it to devbox or keep the action.

[josvazg]

Only one concern. You removed the action that manages Kind installation and configuration. The make target run-kind (that calls the script create_kind_cluster.sh) only handle configuration of the Kind cluster. It works only because the runner (ubuntu-latest) has it pre-installed, however, we have no control on the version we are running. I'd ad it to devbox or keep the action.

Due to how expensive was to test this, I am thinking to send a PR just with that right after this one. I can even send the PR and merge this one only after the new PR is ready for review. WDYT @helderjs
Note the follow up PR can be tested normally once this is merged, as we will be validating things that are not in the workflows anymore.

[josvazg]

Follow up #2870