This post is about the desired behaviour for the upload-resource command in Charmcraft. Some of the functionality is there, other needs to be implemented.
Spec
The upload-resource command will support both resource types, file and oci-image.
The signature of the command will be:
charmcraft upload-resource charm-name resource-name [--filepath=PATH|--image=DIGEST]
The charm and resource names identifies the resource for which charmcraft will upload the content, and are both mandatory parameters. After that, one of --filepath or --image must be specified, for file and oci-image resource types correspondingly.
In both cases the developer needs to own or be a collaborator of the charm related to the resource that is uploading.
For the file case
The option --filepath must indicate a readable local file; charmcraft will just upload that content to Charmhub.
For the OCI image case
The option --image must indicate an OCI image’s digest, being it in the short or long form (e.g.: 70aa8983ec5c or sha256:70aa8983ec5cea7bc143af188b4bdc424fa405184d56dcbdfd9df672ade85249). Note that the image name is not needed (as the resource is already identified) and a tag is not allowed (the image needs to be univocally identified). Likewise, only a digest is accepted, not an URL to generic external registry.
For the case of the OCI image, charmcraft will first check if that specific image is available in the Canonical’s Registry, and just use it if that’s the case. If not, it will try to get it from the local OCI repository, push it to the Canonical’s Registry, and then use it. Otherwise it will fail with a proper error message. Note that in the case of using the “short form” of the digest, the image needs to be present locally so its proper ID (the “long form”) could be retrieved.
The following is the case of charmcraft using the image already present in the Canonical’s registry:
$ charmcraft upload-resource my-charm my-resource --image=sha256:c8f0dbc0d5a5e3aef7281a4d3941e97f204390b2cba9de6c117341361cbe84e4
Using the OCI image from Canonical's registry
Revision 7 created of resource 'my-resource' for charm 'my-charm'
The following is the case of charmcraft needing to push the image first:
$ charmcraft upload-resource mycharm my-resource --image=sha256:70aa8983ec5cea7bc143af188b4bdc424fa405184d56dcbdfd9df672ade85249
Remote image not found, uploading from local registry
Image uploaded, new remote digest: sha256:29b027d656acae6e50693a2ec063d40c7de59a2f7b4c0d62c765d2f1cbde616c
Revision 5 created of resource 'my-resource' for charm 'my-charm'
One detail to take into consideration. When charmcraft pushes the local image to Canonical’s registry, the remote manifest ends up slightly different to the local one. This is deterministic, so future operations will continue to use the same manifest, but it does take some work each time to compute the target manifest.
A note about authentication
As said above in the general case, the developer needs to own or be a collaborator of the related charm.
This is specially true when working with the Canonical’s registry. All the interactions with the registry are authenticated, and the images there live under a path that includes the charm id.
So when charmcraft goes to the registry and asks for a digest (to reuse it), it would really check if there’s an image for that charm (that the client can see) with that digest. Similarly, when an image is uploaded, it will be uploaded only for the indicated charm.