Artifacts may contain other files types, not just YAML files, meaning the
semantic YAML diff provided by `dyff` is not a safe default.
This change implements purely textual diffing using the `diff` command line
tool. This tool can be overridden by users using the `FLUX_EXTERNAL_DIFF`
environment variable.
Users that store Kubernetes resource manifests in the artifact can re-enable
the semantic YAML diff behavior using the `--semantic-diff yaml` flag.
The arguments to the diff subcommand may be:
* A directory
* A .tar.gz or .tgz file
* An OCI url
* An individual file
The two arguments to the command are treated the same way, allowing users to
diff in either direction.
Signed-off-by: Florian Forster <fforster@gitlab.com>
Also updates the list of options passed to `dyff.CompareInputFiles` to be the
same as in the internal `build` package.
Signed-off-by: Florian Forster <fforster@gitlab.com>
I was hoping to use `flux diff artifact` as part of a CI pipeline to show the
difference between the merge request and the currently deployed artifact. The
existing implementation doesn't work for us, since it only compares the
checksums.
This commit changes the output produced by `flux diff artifact` to a list of
changes in human readable form. The code is using the `dyff` package to produce
a semantic diff of the YAML files. That means, for example, that changes in the
order of map fields are ignored, while changes in the order of lists are not.
Example output:
```
$ ./bin/flux diff artifact "oci://${IMAGE}" --path=example-service/
spec.replicas (apps/v1/Deployment/example-service-t205j6/backend-production)
± value change
- 1
+ 7
✗ "oci://registry.gitlab.com/${REDACTED}/example-service-t205j6/deploy:production" and "example-service/" differ
```
The new `--brief` / `-q` flag enables users to revert to the previous behavior
of only printing a has changed/has not changed line.
Signed-off-by: Florian Forster <fforster@gitlab.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>
This makes the pushed artifact have the exact same hash if the contents
are the same.
E.g
```
flux push artifact oci://repo/image:tag1 --source deploy --revision="test" --path=deploy --reproducible
flux push artifact oci://repo/image:tag2 --source deploy --revision="test" --path=deploy --reproducible
```
will both result in the same sha hash, tagged with `tag1` and `tag2`.
This is useful when producing flux artifacts in a monorepo setup where
you don't want to unnecessarily push new artifacts unless something has
actually changed.
Signed-off-by: frekw <fredrik@warnsberg.se>
Allow configuring the list of host key algorithms to use for
SSH connections initialized by the CLI during bootstrap.
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
This change introduces two new flags to `create source oci` for
providing the values to the
`OCIRepository.spec.verify.matchOIDCIdentity.(issuer,subject)` fields.
Signed-off-by: Max Jonas Werner <mail@makk.es>
Signed-off-by: toomaj <toomaj@tuta.io>
Set tokenAuth to true with withBearerToken
Signed-off-by: toomaj <toomaj@tuta.io>
Set breaderToken if tokenAuth & withBearerToken were set
Signed-off-by: toomaj <toomaj@tuta.io>
This command can be used to replicate the behavior of the
Flux Kustomization post-build substitutions.
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
Add an optional flag called `--registry-creds` to the bootstrap
command for generating an image pull secret for container images
stored in private registries.
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
This can happen when Custom Resource Definitions do not exist on the
cluster. For example, because only a subset of the Flux controllers are
installed on the cluster.
Previously, the detection was based on a combination of error type and
string matching. However, a more reliable (and maintained)
`apimeta.IsNoMatchError` checker is available upstream. Making it less
likely this suddenly stops to matching properly when Kubernetes changes
things.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
