Make it easier to release charms in CI and in general
Metadata
Current evaluation
Single-command charm upload and release with OCI resources remains unimplemented; upload accepts only existing resource revisions, so users must upload resources first and track returned IDs.
Suggested action: keep open
Reason: The feature remains valid: current `UploadCommand` accepts resources only as `<name>:<revision>`, while `upload-resource --image` creates a separate resource revision. A maintainer explicitly confirmed the request is still applicable, while noting that cross-craft resource UX remains to be designed.
Evaluated by: mr-cal-bot
Impact:
55
Quick Win:
14
Complexity:
62
Confidence:
94
Actionability:
68
Issue body
### What needs to get done
I would like to be able to upload + release both charm and resources in one command, without having to deal with charm revisions and resource revisions directly.
For example:
```
charmcraft upload grafana-k8s_ubuntu-20.04-amd64.charm \
--resource grafana-image=ubuntu/grafana:9.2-22.04_beta \
--resource litestream-image=docker.io/litestream/litestream:0.4.0-beta.2 \
--release edge
```
Specifically:
- The user doesn't need to deal with `skopeo` or local image registry themselves.
- The user doesn't need to keep track of integer ids for charm/resource between multiple commands to release a charm.
### Why it needs to get done
- Currently we're relying on a github action with >20kLOC which is difficult to maintain.
- The know-how of releasing a charm is buried deep below piles of github yaml and js.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
55
Quick Win:
14
Complexity:
62
Confidence:
94
Actionability:
68
|
keep open | Single-command charm upload and release with OCI resources remains unimplemented; upload accepts only existing resource revisions, so users must upload resources first and track returned IDs. | |
| qwen/qwen3.6-35b-a3b |
Impact:
70
Quick Win:
17
Complexity:
60
Confidence:
70
Actionability:
60
|
keep open | Feature request for single-command charm upload + release with automatic OCI resource handling. Partially addressed by PRs #255 and #457 (upload --release --resource), but core UX issue remains: users still must manually specify resource revision numbers instead of image references. | |
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
16
Staleness:
25
Complexity:
70
Confidence:
75
Support Request:
0
|
keep open | Feature request to upload and release a charm plus its OCI resources in one command without tracking integer revision IDs. Skopeo integration landed, but upload --resource still requires name:revision format. Maintainers acknowledge it remains applicable and UX is being considered across crafts. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
65
Complexity:
55
Confidence:
75
Support Request:
5
|
keep open | Feature request to simplify charm and resource release in CI via a single command, avoiding manual revision tracking. Currently under discussion after maintainer initially marked it superseded, but author clarified it remains needed. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
65
Complexity:
75
Confidence:
70
Support Request:
5
|
keep open | Feature request for a single command to upload and release charms with OCI resources, avoiding manual revision tracking. Currently under discussion with maintainers planning cross-tool UX, but inactive for ~9 months. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
50
Complexity:
65
Confidence:
85
Support Request:
10
|
keep open | Feature request for a single charmcraft command to upload and release charms with OCI resources without manual revision tracking. Open, under maintainer discussion, awaiting UX design across multiple crafts. |
Update history
No update history recorded yet.
Related work
-
Related To:
charmcraft#457
(confidence 98%)
Merged support for attaching existing resource revisions during `upload --release`, but it does not automate resource creation or revision lookup.
-
Related To:
charmcraft#255
(confidence 98%)
Merged the ability to release directly from `upload`, addressing only the upload-and-release portion of the request.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1979 `charmcraft upload` should allow a user to also release the charm | charmcraft | open | Requests single-command charm upload+release with automatic OCI resource handling. --release flag already exists; remaining gap is resource upload by image reference instead of revision number. | |
| #457 Allow including resources when releasing charms directly in the upload command (CRAFT-381). | charmcraft | merged | Merged PR #457 (b5d735b4), adding --resource support to upload --release and fixing #456; the fix shipped in Charmcraft 1.1.2. | |
| #126 Add a "--release" option to the "upload" command | charmcraft | closed | Implemented charmcraft upload --release in canonical/charmcraft#255 (merge 9064a3f3, feature bc06a62a); #457 added resource support and shipped in Charmcraft 1.1.2. | |
| #847 Improve the 'release' response when resources are automatically released with the charm | charmcraft | open | Enhance charmcraft release output to list resources Charmhub automatically attaches; the backend fix is available, but current output only reports resources passed with --resource. | |
| #839 Upload resources on charmcraft upload when specified as upstream-resource in the metadata file | charmcraft | closed | Feature request to auto-upload OCI resources during `charmcraft upload` was declined by design: maintainer refused to have Charmcraft copy Docker Hub images into Canonical's registry and cited upload inefficiency; user advised to script it using JSON output. |