Promote can cause regressions if the charm has several bases and architectures

[gabrielcocenza]

Bug Description

IMO this is not fault of the promote action itself because apparently there is no way to run charmcraft release targeting a specific base/arch.

However, the current algorithm maps the Bases with the charm revisions and resources and will call several times charmcraft release. See one e.g, specifically the final logs:

/snap/bin/charmcraft release hardware-observer --revision 15 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 15 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 213 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 119 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 118 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 15 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 215 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 119 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 118 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 216 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 217 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 119 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1
/snap/bin/charmcraft release hardware-observer --revision 118 --channel latest/stable --resource perccli-deb:1 --resource sas2ircu-bin:1 --resource sas3ircu-bin:1 --resource storcli-deb:1

On charmcraft 2 was common to have a single charm file for one or more ubuntu bases, so if the revision is compatible with a certain base, it will change and this can cause severe regressions. Hardware Observer for example had a regression from revision 218 to 15 because of this.

I've opened a bug at charmcraft canonical/charmcraft#2243 and I think at least older projects that generated charm files for more than one base to stop using this action.

To Reproduce

described in the charmhub bug

Environment

Not applicable

Relevant log output

N.A

Additional context

No response