[visualphoenix]

Adds optional -manifest_output and -config_output to the digest tool, surfaced on HelmOCIDigestInfo and as manifest / config output groups so a BUILD file can reach them.

A consumer that pushes a chart has to PUT the manifest body, not just name it by digest. Emitting the bytes saves it reimplementing the annotation generation and config serialization to produce something that matches.

[abrisco]

Thanks! Does this reveal non-deterministic behavior in the marshalling? That seems like the better fix assuming the re-computation isn't crazy expensive.

[visualphoenix]

honestly - i didnt try recomputation - emitting what was already calculated seemed easiest

the marshalling is fine - it is deterministic - i pushed to a local registry and compared against helm and the digests matched - i shouldnt have implied that there was nondeterminism - i've just been bitten before by golang marshalling/unmarshalling reordering things

i push other assets from a service that reads out of the bazel remote cache - so i was hoping to avoid reimplementing the annotation and config serialization to get the bytes

happy to drop this if you'd rather the standard practice be for all consumers to recompute - in the meantime i'll squash and rewrite the commit msg and pr desc

[visualphoenix]

squashed and reworded - commit msg and pr desc match now

[visualphoenix]

are you saying you’d prefer to have a different verb for getting at these other bits and not making them outputs of the helm_oci_digest? Like helm_oci_manifest etc?

[rdark]

@visualphoenix FYI - I proposed an helm_oci_manifest in #305 which is a rules_img image_manifest with a push spec. Once rules_img pushes a release with rules_img#805 in, the target manifest should be byte identical with helm push

[abrisco]

Thank you!