### 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 ```