How to publish a resource to Charmhub
See also:
You have a charm that you’ve published to Charmhub. You also have a resource name that has been associated to your charm. This document shows you how you can now publish your resource to Charmhub too. Because resources are defined in a charm’s metadata.yaml
, they are intrinsically linked to a charm, so there is no need to register them separately in Charmhub—all you need to do is upload the resource.
Other charms may have resources with the same name, but this is not a problem; references to resources always contain the charm name and resource name.
Contents:
Upload a file resource
To upload a file resource, follow the template below:
jdoe@machine:~/blogsystem$ charmcraft upload-resource my-super-charm someresource --filepath=/tmp/superdb.bin
Revision 1 created of resource 'someresource' for charm 'my-super-charm'
To update a pre-uploaded resource, run the upload command again. The result will be a new revision.
jdoe@machine:~/blogsystem$ charmcraft upload-resource my-super-charm someresource --filepath=/tmp/superdb.bin
Revision 2 created of resource 'someresource' for charm 'my-super-charm'
To verify all the revisions for a specific resource, execute:
jdoe@machine:~/blogsystem$ charmcraft resource-revisions my-super-charm someresource
Revision Created at Size
2 2021-03-05 192.3K
1 2021-03-05 204.9K
Upload an OCI-image resource
Uploading oci-image
resources is similar to uploading file
resources, but with a few different parameters to the command.
For example, if an oci-image
is defined in metadata.yaml
like so:
# ...
resources:
redis-image:
type: oci-image
description: OCI image for Redis
# ...
It can be uploaded like so:
# charmcraft upload-resource --image <image digest> <charm name> <resource name>
$ charmcraft upload-resource my-super-charm redis-image --image=sha256:64aa8983ec5cea7bc143af18829836914fa405184d56dcbdfd9df672ade85249
Revision 1 created of resource 'redis-image' for charm 'my-super-charm'
The option --image
must indicate an OCI image’s digest, being it in the short or long form (e.g.: 70aa8983ec5c
or sha256:64aa8983ec5cea7bc143af18829836914fa405184d56dcbdfd9df672ade85249
).
Charmcraft will first check if that specific image is available in Canonical’s Registry, and just use it if that’s the case. If not, it will try to get it from the developer’s local OCI repository (needs dockerd
to be installed and running), push it to the Canonical’s Registry, and then use it.
When using the “short form” of the digest, the image needs to be present locally so its proper ID (the “long form”) can be retrieved.
The following is an example of charmcraft
using an image already present in Canonical’s Registry:
$ charmcraft upload-resource my-super-charm redis-image --image=sha256:c8f0dbc0d5a5e3aef7281a4d3941e97f204390b2cba9de6c117341361cbe84e4
Using the OCI image from Canonical's registry
Revision 7 created of resource 'redis-image' for charm 'my-super-charm'
The following is the case of charmcraft
needing to push the image first:
$ charmcraft upload-resource my-super-charm redis-image --image=sha256:70aa8983ec5cea7bc143af188b4bdc424fa405184d56dcbdfd9df672ade85249
Remote image not found, uploading from local registry
Image uploaded, new remote digest: sha256:29b027d656acae6e50693a2ec063d40c7de59a2f7b4c0d62c765d2f1cbde616c
Revision 5 created of resource 'redis-image' for charm 'my-super-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.
Last updated a month ago.