Open rajatjindal opened 5 months ago
In addition to the inline YAML comment I would maybe also emit a stderr notice to help with the common case of piping the output, e.g.
$ spin kube scaffold --from my-image
Note: No tag or digest specified; resolved "latest" tag to "sha256:abc...".
apiVersion: core.spinoperator.dev/v1alpha1
[...]
spec:
# Image resolved from "latest" tag at 2024-03-28T08:54Z
image: "my-image@sha256:abc..."
It may also make sense to have something like a --resolve
flag to turn on this behavior for other tags like :dev
. I think the behavior could look something like:
--resolve
, resolve the tag (or latest
) to a digest--resolve
was not specified, print message to stderrI think the current thread assumes the image tag exists on the local machine. Does spin build && spin registry push bacongobbler/hello-rust:latest
build and store bacongobbler/hello-rust:latest
in the local image store? I wasn't sure if those commands put the "Spin image" into the local image store or just assembles the image and the tag on-the-fly.
I was thinking this would fetch the digest from the registry, but that might have slightly wonky UX... :thinking:
There is a request from a user to use latest tag for SpinKube artifacts and for that there is a desire to expose imagePullPolicy in the SpinApp CRD.
The mutable tags have been known for causing troubles and we want to evaluate if we can add an option to
scaffold
command to resolve the sha256 for latest tag using kube plugin, and use that in the SpinApp resource automatically.This will ensure user can still continue to use latest tag, but from the cluster perspective, we will be using sha256.
This issue is to do a poc for this feature and see if it helps satisfy the user requirement.
The dev experience may look something like follows:
Notice, the version is ommitted from the
--from my-image
arg.