-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Today, skupper uses a locally installed docker command to determine the SHA of the images it would use, when the subcommand version --output is issued.
This behavior has some issues:
- It silently uses docker, which gives the user the impression that the information is coming from the skupper binary itself, not from a query to a registry
- It depends on docker being installed locally, which is not otherwise a required dependency
- It fails in a few different scenarios (docker not available, network problems, etc), without returning a non-zero exit status
- It adds time to the execution of the command
Alternatives:
- Make SHA retrieval an option, whose documentation clearly indicates it will be fetched online (something like
--retrieve-digest); fail the command whenever any of the entries is not properly retrieved for any reason - Remove it altogether and create a job aid on documentation, on how to retrieve SHAs using different methods (docker, podman, skopeo)
- Keep as-is, but document fact that SHAs are retrieved in runtime, derived from the baked-in tags by accessing the registry. And change it to return non-zero when any of the SHAs retrieval fails
See my original entry on skupperproject/skupper#2043:
That said, I'd like to take a step back: why do we include the digests in the output in the first place?
That is information that is not baked in the binary; we're using docker to derive it at runtime from the tag.
The tag is the thing that is baked in, and that we need to report, and it is already present on the output JSON.
It should be simple for a user of that JSON to use whatever tool they prefer to get the digests from the tags.
I think we should consider removing the digests altogether: it adds complexity, depends too much on the environment, is prone to fail and adds little value; value which is easily achieved by external tools consuming the rest of the output information.