Consider adding an optional cli argument for base (including the arch) for charm release
Metadata
Current evaluation
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.
Suggested action: needs triage
Reason: The issue has no labels, no maintainer comments, and no assignee after 516 days. The ReleaseCommand in charmcraft/application/commands/store.py (line 759) confirms no --base or --arch argument exists. The underlying craft_store publisher.ReleaseRequest model would need to support base/arch targeting, making this a non-trivial feature spanning multiple layers. The reporter's own edit notes this may not affect charmcraft 3+ projects, reducing urgency.
Impact:
50
Quick Win:
22.5
Staleness:
75
Complexity:
55
Confidence:
70
Support Request:
10
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 |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
50
Quick Win:
22.5
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. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
40
Confidence:
70
Support Request:
10
|
needs triage | Proposes adding an optional base and architecture argument to the charmcraft release CLI to prevent resource attachment errors for older bases. Open, unassigned, and inactive for 300 days, awaiting triage. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.