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)
- 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)
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>