`charmcraft upload` should be able to take several `*.charm` files at once
Metadata
Current evaluation
Closed by the reporter as expected behaviour: maintainers explained Charmhub supports charms of different bases per revision, so per-base .charm files are uploaded separately and Juju picks the right one. No code change.
Resolution: closed not a bug
Reason: No PR or commit was involved. wgrant explained on 2023-10-04 that Charmhub handles charms with differing bases (OS/series/arch) like the Snap Store handles architectures: upload both charms, release both to latest/stable, and `charmcraft status` shows a Base column per revision with Juju selecting the matching one. sed-i confirmed on 2023-10-05 that this is the correct approach and closed the issue.
Evaluated by: mr-cal-bot
No scores available.
Issue body
### What needs to get done
There seems to be an inconsistency in how `charmcraft upload` creates "artifacts" on charmhub.io.
One of our o11y charms, grafana-agent, is a subordinate charm, so we need it to run on 20.04 and 22.04.
We can no longer produces a single charm file (`build-on: [22.04]; run-on: [20.04, 22.04]`) because the [22.04-built charm does not run on 20.04](https://github.com/canonical/grafana-agent-operator/issues/5) (libssl.so.3 isn't there in 20.04).
Splitting bases -- having 1:1 match between build-on and run-on -- [works](https://github.com/canonical/grafana-agent-k8s-operator/pull/252).
My question: how do I `charmcraft upload` two separate *.charm files so they appear "all in one" on charmhub?
## Use case 1: multiple `run-on` for the same `build-on`
```yaml
bases:
- build-on:
- name: "ubuntu"
channel: "22.04"
architectures: ["amd64"]
run-on:
- name: "ubuntu"
channel: "22.04"
architectures: ["amd64"]
- name: "ubuntu"
channel: "20.04"
architectures: ["amd64"]
```
Output is a single file:
- `grafana-agent_ubuntu-22.04-amd64_ubuntu-20.04-amd64.charm`
Charmhub artifacts are multiple series in the same channel/revision:
## Use case 2: 1-to-1 match between `run-on` and `build-on`
```yaml
bases:
- build-on:
- name: "ubuntu"
channel: "20.04"
architectures: ["amd64"]
run-on:
- name: "ubuntu"
channel: "20.04"
architectures: ["amd64"]
- build-on:
- name: "ubuntu"
channel: "22.04"
architectures: ["amd64"]
run-on:
- name: "ubuntu"
channel: "22.04"
architectures: ["amd64"]
```
Output is two files:
- `grafana-agent_ubuntu-20.04-amd64.charm`
- `grafana-agent_ubuntu-22.04-amd64.charm`
But here it seems impossible to upload both into the same charmhub "artifact":
- I have to upload each file separately, each getting its own revision number.
- Seems like I would have to have a charmhub track per series?
### Why it needs to get done
To maintain consistency in how charmhub handles multiseries artifacts between use cases 1 and 2 above.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed not a bug | Closed by the reporter as expected behaviour: maintainers explained Charmhub supports charms of different bases per revision, so per-base .charm files are uploaded separately and Juju picks the right one. No code change. | |
| stealth/space-bunny-alpha | — | closed not a bug | Closed without code change: wgrant and sergiusens explained that per-base charms are uploaded separately, released to latest/stable, and Juju picks the right revision by base; reporter confirmed this is the correct approach and closed. | |
| stealth/space-bunny-alpha | — | closed not a bug | Question closed as not a bug: maintainers confirmed per-base *.charm files are uploaded separately and released to the same channel, with Juju picking the right revision by base. No code change. | |
| stealth/space-bunny-alpha | — | closed not a bug | Closed after confirmation that separate Ubuntu 20.04 and 22.04 charms can be uploaded to one Charmhub channel, released to latest/stable, and selected by Juju according to their base. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed as working as designed. Clarification confirmed that uploading separate charm files for different bases and releasing them to the same channel is the intended workflow. Juju automatically selects the correct revision, making a multi-file upload feature unnecessary. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed as resolved. Uploading multiple charm files separately and releasing them to the same track is the supported workflow. Charmhub handles base-specific revisions automatically, and Juju selects the correct one at deployment. No code changes needed. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed as not needed. Charmhub natively supports uploading separate charm files for different bases. Juju automatically selects the correct revision based on the target OS and architecture, making a combined upload command unnecessary. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed as works as intended. Maintainers clarified Charmhub already supports multiple base revisions via separate uploads. Releasing each file to the same track allows Juju to automatically select the correct revision. No code changes needed. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #194 charmcraft upload should take a path directly | charmcraft | closed | Positional upload paths were implemented; automatic charm-file discovery was split into #312 and rejected because bases builds may produce multiple complex artifacts. | |
| #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. | |
| #148 make charm take zips | charmcraft | closed | Legacy-store support for uploading Charmcraft-built .charm files was implemented and released in charm, resolving the request. |