When recursively diffing Kustomization objects on a cluster, each
Kustomization is built and then a server-side dry-run apply is
performed. This isn't practical to perform if the Kustomization
references a remote cluster via `kubeConfig.secretRef`.
Currently, because it's not skipped, it's treated as though it's
being applied to the context cluster, not the remote cluter, which
results in an incorrect diff.
Instead, write out special message / warnings indicating that it
has been skipped:
```
► Kustomization/my-ns/my-kst skipped: diff not supported for remote clusters
```
Signed-off-by: Milas Bowman <devnull@milas.dev>
- Add provider flag to `flux create source git` command with supported values: azure, generic.
- Unit tests validating the generated yaml and error conditions.
Signed-off-by: Dipti Pai <diptipai89@outlook.com>
The `create source chart` command supports all HelmChart.spec fields
except `.valuesFiles` and `ignoreMissingValuesFiles` as these are
assumingly rarely used fields and the CLI usually only supports
commonly used ones.
closes#4760
Co-authored-by: Stefan Prodan <stefan.prodan@gmail.com>
Signed-off-by: Max Jonas Werner <mail@makk.es>
If implemented users will be able to use a local kustomization file while
retrieving status from the live kustomization file.
Signed-off-by: Soule BA <soule@weave.works>
If implemented, user will be able to ignore files when using `build
kustomization` and `diff kustomization` both with .sourceignore and
`ignore-paths` flag.
Signed-off-by: Soule BA <bah.soule@gmail.com>
The `\b` in the regular expression ensures we only match with a
hexadecimal notation as awhole, while still allowing to match with
e.g. `sha1:...` which would not have been possible by using `\W`
as this includes `_`.
Signed-off-by: Hidde Beydals <hello@hidde.co>
If this is implemented, it will not assume that access to a kubeconfig
is guaranteed even if just for retrieving configured namespace.
Signed-off-by: Soule BA <soule@weave.works>
I've noticed during CI, that the current command
already expected a configured Docker client to
push artifacts to authenticated registries.
Some users might not want to have the Docker client
in their process (like a CI job) or build an handcrafted
config.json file.
This would allow this kind of behavior:
```
flux push artifact oci://my-registry.dev/foo:v1 \
--source xxx \
--revision xxx \
--path . \
--creds $TOKEN # Authenticate via "Bearer $TOKEN" Authorization header
```
Or via Autologin:
```
flux push artifact oci://012345678901.dkr.ecr.us-east-1.amazonaws.com/foo:v1 \
--source xxx \
--revision xxx \
--path . \
--provider aws
```
This has been implemented for:
* flux push artifact
* flux list artifact
* flux tag artifact
* flux pull artifact
This will require another PR in https://github.com/fluxcd/pkg/pull/352
Signed-off-by: Adrien Fillon <adrien.fillon@manomano.com>
