`charmcraft upload` should be able to take several `*.charm` files at once
Metadata
Current evaluation
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.
Suggested action: —
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 |
|---|---|---|---|---|
| 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. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed as resolved. Charmhub natively supports multi-base charms. Uploading separate charm files and releasing them to the same channel works correctly, with Juju automatically selecting the appropriate revision based on the target base. No code changes required. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #669 `charmcraft` should allow setting versions for `juju status` | charmcraft | closed | Closed as multiple topics were addressed separately. Version file generation is tracked in issue #37, while file inclusion uses parts.charm.prime in charmcraft.yaml. The development workflow documentation update was opened as issue #695. No direct fix implemented here. |