Consider adding an optional cli argument for base (including the arch) for charm release
Metadata
Current evaluation
Request for an optional base and architecture selector on `charmcraft release` to prevent multi-base legacy charm promotions from changing unrelated architectures; the CLI still lacks this option.
Suggested action: needs triage
Reason: The report provides concrete status and command examples showing releases of revisions 10 and 12 unintentionally changing 16.04, 18.04, and 20.04 architectures, while the current ReleaseCommand still accepts only revision, channel, and resource options. The use case is clear, but it has no labels, maintainer response, or confirmation that Charmhub's release API supports base-specific targeting.
Evaluated by: mr-cal-bot
Impact:
65
Quick Win:
19
Complexity:
65
Confidence:
91
Actionability:
82
Issue body
### Bug Description
This is kind of a bug/necessary feature that I've steeped on.
Projects using the release workflow from [charm-actions](https://github.com/canonical/charming-actions/tree/main/promote-charm) can start facing issues if it's not possible to target a specific base for releasing.
Let's take an example that recently happened to me:
Charm `prometheus-libvirt-exporter` is an old charm that has old bases like 16.04.
My release using the workflow was not working because the `ubuntu 16.04 (amd64)` didn't have the resources attached. See the [error](https://github.com/canonical/charm-prometheus-libvirt-exporter/actions/runs/14221483738/job/39850382055)
```
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 10 --channel latest/candidate
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 12 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 78 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 79 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 53 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 49 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 80 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 81 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 50 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 47 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0
Store operation failed:
- api-error: Resource 'dashboards' missing from this 'prometheus-libvirt-exporter' release or any previously released revisions on channel: candidate
- api-error: Resource 'prometheus-libvirt-exporter' missing from this 'prometheus-libvirt-exporter' release or any previously released revisions on channel: candidate
Full execution log: '/home/runner/.local/state/charmcraft/log/charmcraft-20250402-135819.773658.log'
```
The way that the workflow works is to map a certain Base with the charm revision and resources and then call the charmcraft binary. See in the logs shared that it calls using several revisions: 10, 12, 78 and etc because of this mapping. Unfortunately, I don't have the charmcraft status before the run, but see[ this one](https://pastebin.canonical.com/p/kbfmxSbrX4/) for example.
For some reason version 10 wasn't with the necessary resources:
```
charmcraft status prometheus-libvirt-exporter
Track Base Channel Version Revision Resources
latest ubuntu 16.04 (all) stable 7 7 dashboards (r0), prometheus-libvirt-exporter (r0)
candidate 7 7 dashboards (r0), prometheus-libvirt-exporter (r0)
beta ↑ ↑ ↑
edge ↑ ↑ ↑
ubuntu 16.04 (amd64) stable 7 7 -
candidate 0c77524 10 -
beta ↑ ↑ ↑
edge 0c77524 10 -
```
To unblock this I've manually run `charmcraft release prometheus-libvirt-exporter --revision 10 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0` to add the resource, but this unfortunately won't target just for the `ubuntu 16.04 (amd64)`
See that after this the ubuntu 18.04 (amd64) also changed the candidate channel:
```
ubuntu 18.04 (amd64) stable 558c66e 12 dashboards (r0), prometheus-libvirt-exporter (r0)
candidate 0c77524 10 dashboards (r0), prometheus-libvirt-exporter (r0)
beta ↑ ↑ ↑
edge 558c66e 12 dashboards (r0), prometheus-libvirt-exporter (r0)
```
If now I run the workflow from edge to candidate it will release version `10` for `18.04 (amd64)` which is an regression.
Our team faced a similar issue before because it's very easy to miss those details when you have several base/archs.
In summary, because the workflow runs several `charmcraft release` with different charm revisions, this can cause unwanted regressions that can be dangerous for the products.
Another error that happened is to `ubuntu 20.04 (amd64) `:
```
ubuntu 20.04 (amd64) stable 58 58 dashboards (r0), prometheus-libvirt-exporter (r0)
candidate 558c66e 12 dashboards (r0), prometheus-libvirt-exporter (r0)
beta ↑ ↑ ↑
edge 0c77524 10 dashboards (r0), prometheus-libvirt-exporter (r0)
```
Version 12 initially came from `ubuntu 18.04 (amd64)` and because the workflow run `/snap/bin/charmcraft release prometheus-libvirt-exporter --revision 12 --channel latest/candidate --resource dashboards:0 --resource prometheus-libvirt-exporter:0` the candidate changed probably from 58 to 12 and the edge from 58 to 10
Running the promote workflow again changed from 12 to 10:
```
ubuntu 20.04 (amd64) stable 58 58 dashboards (r0), prometheus-libvirt-exporter (r0)
candidate 0c77524 10 dashboards (r0), prometheus-libvirt-exporter (r0)
beta ↑ ↑ ↑
```
If someone now run the workflow from candidate to edge see that this will make a massive regression.
Having the option to target a specific base and arch can solve this issue in my point of view and then using the charming-actions can be more reliable.
[EDIT] I think this bug might not happen for projects using charmcraft 3 because it generates specific files for each base, but older projects using charmcraft 2 that generates single charm file for one or more bases, might face this issue.
### To Reproduce
Already provided in the description
### Environment
Not applicable
### charmcraft.yaml
```yaml
Not applicable
```
### Relevant log output
```shell
Already provided in the description
```
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
65
Quick Win:
19
Complexity:
65
Confidence:
91
Actionability:
82
|
needs triage | Request for an optional base and architecture selector on `charmcraft release` to prevent multi-base legacy charm promotions from changing unrelated architectures; the CLI still lacks this option. | |
| stealth/space-bunny-alpha |
Impact:
66
Quick Win:
13
Complexity:
74
Confidence:
86
Actionability:
76
|
needs triage | Untriaged request to add a base-and-architecture selector to charmcraft release; the current CLI supports only revision, channels, and resources, so cross-base promotion regressions remain possible | |
| qwen/qwen3.6-35b-a3b |
Impact:
70
Quick Win:
34
Complexity:
40
Confidence:
80
Actionability:
80
|
keep open | Feature request to add optional --base argument to charmcraft release command to target specific base/arch and prevent cross-base regressions during charm publishing. | |
| qwen/qwen3.8-27b |
Impact:
50
Quick Win:
22
Staleness:
75
Complexity:
55
Confidence:
70
Support Request:
10
|
needs triage | Feature request to add optional base/arch argument to charmcraft release command to prevent unwanted cross-base regressions during multi-base releases. No maintainer response, no labels, 0 comments, last activity 381 days ago. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
35
Confidence:
75
Support Request:
10
|
needs triage | Request to add optional CLI argument to charmcraft release for targeting specific bases/archs to prevent cross-base regressions. Untriaged and inactive for over a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
65
Confidence:
90
Support Request:
10
|
needs triage | Request to add optional CLI argument to charmcraft release to target specific base/arch, preventing unintended regressions across architectures in charmcraft 2 workflows. Currently untriaged and inactive. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
80
Complexity:
40
Confidence:
70
Support Request:
10
|
needs triage | Feature request to add a CLI argument for specifying base/arch during charm release to prevent unintended regressions across multiple bases. Currently unassessed and inactive for over a year. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.