Promoting charms in CI? There's a new charming action in town!

I know what you’re thinking: “Luca, I can just charmcraft release my-charm --channel ..., why would I need anything else”; well, here’s why!

Manual promotions have some issues

There are a few issues with manually promoting a charm from a channel to another:

  • we don’t have charmcraft promote yet, so you need to:
    1. run charmcraft status to figure out which revision is in which channel
    2. run charmcraft release for the actual promotion (be careful with typos!)
    3. repeat that for every base and architecture
  • there’s no traceability for who and when promoted what:
    1. your manager asks in the team chat to promote cool-charm from latest/candidate to latest/stable
    2. you see the message after a couple of hours: has anyone done it? Should you do it?
    3. have fun asking all the people in the team to figure it out

This process is very error-prone: you made a typo in the revision number when releasing to stable? Enjoy explaining that to customers!

The automated way

There’s a new charming-action to promote charms now!


This allows you to promote a charm from a channel to another channel; the promotion will happen for all bases and all architectures, so you don’t have to worry about anything!

To use it, just make a workflow like the one we have here. Give it a try!

Taking it a step further

In the Observability team, we currently promote all of our charms, on a cadence, to the next risk track (i.e., we shift edgebetacandidatestable). Imagine doing the process I described above, repeated for ~20 charms, on multiple architectures, every two weeks: it’s about

20 repos * 2 bases * (3 channels + 1 status) = 160 commands

With the promote-charm action, we reduced it to about (20 repos * 3 promotions =) 60 manual clicks, but isn’t that still very boring?

That’s why I made the promote train action: this automates all of what I just described, so that now we only have to do one, error-free, click. :tada:


Hi Luca

Thanks for the sharing.

Our team also have something similar. But use the dropdown for standard tracks edge->candidate, candidate->stable to avoid some fat finger.

Here is the promote.yaml

Promote train sounds amazing. We have been wanting to do that in our team as well so we 'll probably be copy-pasting soon. Regarding the promote-charm action, what’s the benefit it has over using the release-charm action (e.g. in this way)?

We also have a dropdown just like that one :smiley:

There are two main issues with using the release-charm action for promotions:

  • in your example, if you have multiple bases/architectures, release-charm would only promote one of them (e.g., you build on 20.04 and 22.04, but only promote the 22.04 channels);
  • release-charm tries to create a tag and GitHub release (see the code).
1 Like