When running `helm upgrade --install` on a non-existent release, the
--server-side flag was not being passed to the install action. This
caused the install to always use server-side apply (the default),
ignoring --server-side=false.
Copy ServerSideApply and ForceConflicts from the upgrade client to the
install client when falling back to install.
Fixes#31627
Signed-off-by: Evans Mungai <mbuevans@gmail.com>
(cherry picked from commit 2dc581dc1c)
add missing coverage for the positive case where cluster-scoped resources (like ClusterRole or Namespace) should work correctly
Signed-off-by: Mohsen Mottaghi <mohsenmottaghi@outlook.com>
(cherry picked from commit a1543d5947)
Adding some tests for multi namespace deployment, simulate restrcited rbac access and mixed namespace scope and cluster scope resources
Signed-off-by: Mohsen Mottaghi <mohsenmottaghi@outlook.com>
(cherry picked from commit dd44f4ecd0)
```
Error: pkg/action/release_testing.go:60:57: unexported-return: exported method Run returns unexported type action.executeShutdownFunc, which can be annoying to use (revive)
func (r *ReleaseTesting) Run(name string) (ri.Releaser, executeShutdownFunc, error) {
```
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
(cherry picked from commit 45c5f3aaca)
This ensures that when `helm uninstall` is run with `--keep-history`
any release in a `deployed` state other than the last release (e.g.
due to a failed upgrade) is being marked as `superseded`.
As a by-effect, running `helm upgrade` on a release which has been
uninstalled after an upgrade failure now no longer works. But instead
fails with a `"<name>" has no deployed releases` error. Which is the
(likely) intended behavior, and prevents other side-effects like
rolling back to a release version which happened before the uninstall
if `--atomic` (or `--rollback-on-failure`) was provided.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
(cherry picked from commit 2f1ecc7100)
GitHub Actions has a cache of tools, like Go, and it does not update
this cache when a new version comes out. It can take more than a week
for a new version to be available.
This change forces the action to check if a newer version is available
than is in the cache.
Closes#31634
Signed-off-by: Matt Farina <matt.farina@suse.com>
(cherry picked from commit 8f636b5bd2)
- v3.18.5 switched jsonschema and began resolving external $ref
at compile-time, exposing missing urn handling
(“no URLLoader registered for urn:…”).
- Add urn scheme loader and pluggable URNResolver. If unresolved, log
a warning and return a permissive true schema (back-compat).
- Apply to pkg/chart/v2 and internal/chart/v3 validators. Not sure about
that
Note: external URNs need AddResource/Resolver (the CLI uses --map for
this). Warning may appear twice since both validators run.
Another strategy could be to add the option to import more "external
schema" explicitly but it is another PR. Something similar to `--map`
from jsonschema package
(santhosh-tekuri/jsonschema@ed65924).
Close: #31170
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
(cherry picked from commit 03bb62f63d)
The kube client logging is based on the actionConfig logging. This
is setup to use slog.Default() before the logging flags are parsed
and logging is setup.
newRootCmdWithConfig changes the logging but it wasn't picked up
for actionConfig or the kube client. This change updates the logging
to include any changes.
Signed-off-by: Matt Farina <matt.farina@suse.com>
(cherry picked from commit 936cd328ac)
The Makefile LDFLAGS were pointing to an incorrect package path
(helm.sh/helm/v4/pkg/chart/common/util) that doesn't exist, causing
the k8sVersionMajor and k8sVersionMinor variables to silently fail
to be set. This left the hardcoded defaults (1.20) in place.
After this fix, `helm template` now correctly defaults to Kubernetes
v1.34.0 (matching the bundled client-go version) instead of v1.20.0,
ensuring charts render with current stable API versions.
Testing scenario:
```sh
cat > /tmp/test-chart/Chart.yaml << 'EOF'
apiVersion: v2
name: test-chart
version: 1.0.0
kubeVersion: ">= 1.28.0-0"
EOF
./bin/helm template test-release /tmp/test-chart
cat > /tmp/test-chart-fail/Chart.yaml << 'EOF'
apiVersion: v2
name: test-chart-fail
version: 1.0.0
kubeVersion: ">= 1.35.0-0"
EOF
./bin/helm template test-release /tmp/test-chart-fail
Exit code 1
Error: chart requires kubeVersion: >= 1.35.0-0 which is incompatible with Kubernetes v1.34.0
```
Fixes#31508Closes#31501Closes#31502
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
(cherry picked from commit b6a8c65216)
Note, when time is not available, the builds are not reproducible.
This problem would only happen when an SDK user is using parts of
the API to build their own tooling. Helm will consistently inject
the dates through the higher level APIs.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Building the same chart into an archive multiple times will have
the same sha256 hash.
Perviously, the time in the headers for a file was time.Now() which
changed each time. The time is now collected from the operating
system when the file is loaded and this time is used.
Fixes: #3612
Signed-off-by: Matt Farina <matt.farina@suse.com>
Evans Mungai
Zadkiel AHARONIAN
Mohsen Mottaghi
Calvin Bui
Benoit Tigeot
Michelle Fernandez Bieber
Michelle Fernandez Bieber
tison
Feruzjon Muyassarov
LinPr
Hidde Beydals
George Jenkins
Matt Farina
yxxhero
Fish-pro
Scott Rigby
Matheus Pimenta