I think that we should instead implement this as part of duffle push

Per a conversation with @radu-matei in #cnab

1.) When we duffle push a bundle that hasn't been pushed, we should first:

• Push the invocation image
• Obtain the digest
• Modify the bundle.json to have the digest correctly (and update the reference to be a digested reference)
• Push the bundle

2.) When we duffle push a bundle to another registry, we should

• Not update the bundle.json digest references
• Push the invocation image to the new registry
• Generate a relocation file
• Push the bundle

I don't think it is necessary to generate a relocation mapping file when we duffle push a bundle to another registry. According to a cnab-to-oci issue, the relocation mapping file can be generated as needed from the registry.

(Also, I'm a little confused because I don't see duffle push at master. Is there a pre-req to this issue? Presumably duffle push isn't a 1.0 feature because it depends on the stilll-to-be-written CNAB registries spec.)

@glyn yes, duffle push is not in master. @radu-matei has been working on a version of it in another PR #681 and I wanted to capture this. The original issue was quite old, so I wanted to update it with discussion from slack.

We should also keep in mind cases where the bundle is never pushed, for example:

1. Build a bundle
2. docker push the invocation image
3. Export the bundle as a thick bundle

Exporting the bundle will effectively "freeze" the invocation image and therefore its content digest. But the bundle may still have an undigested reference to the invocation image and could therefore end up executing a different image.

Circling back on the point of generating a relocation map as part of the push process I think I agree with @glyn - we can generate the relocation map based on the information in the OCI registry - stored bundle.json and the OCI index.

#828 deals with the workflow build -> export.