Problem
Some charms maintain multiple tracks (e.g. track/2.0, track/3.0) with separate branches that publish to their respective CharmHub channels (e.g. 2.0/edge, 3.0/edge).
The current publish-artifacts.yml workflow takes a static channel input, which works well for single-track charms publishing from main. However, for multi-track repos the caller needs a way to derive the target channel from the branch name.
How operator-workflows handles this today
canonical/operator-workflows/publish_charm.yaml uses canonical/charming-actions/channel@2.7.0 — a Node.js action that auto-selects the channel based on git context:
| Event |
Branch |
Resolved channel |
| push |
<default branch> |
latest/edge |
| push |
track/<track-name> |
<track-name>/edge |
| push |
any other |
ignored (fails) |
| pull_request |
any → track/<name> |
<name>/edge/pr-<N> |
| pull_request |
any → any |
latest/edge/pr-<N> |
The caller workflow triggers on push: branches: [main, track/**], and the action resolves which channel to publish to automatically. The channel input in operator-workflows is optional — if not provided, it falls back to the charming-actions selection.
Suggested approach for charm-ci
Consider one of:
-
Make channel input optional and add branch-based auto-resolution logic (similar to charming-actions/channel) when not provided. This gives callers zero-config multi-track support.
-
Accept a channel-from-branch boolean that, when true, maps track/X → X/edge and default branch → latest/edge.
-
Document the pattern for callers to add a pre-job that uses canonical/charming-actions/channel and passes the output to the channel input.
Option 1 or 2 would provide the smoothest migration path from operator-workflows.
Context
Problem
Some charms maintain multiple tracks (e.g.
track/2.0,track/3.0) with separate branches that publish to their respective CharmHub channels (e.g.2.0/edge,3.0/edge).The current
publish-artifacts.ymlworkflow takes a staticchannelinput, which works well for single-track charms publishing frommain. However, for multi-track repos the caller needs a way to derive the target channel from the branch name.How operator-workflows handles this today
canonical/operator-workflows/publish_charm.yamlusescanonical/charming-actions/channel@2.7.0— a Node.js action that auto-selects the channel based on git context:<default branch>latest/edgetrack/<track-name><track-name>/edgetrack/<name><name>/edge/pr-<N>latest/edge/pr-<N>The caller workflow triggers on
push: branches: [main, track/**], and the action resolves which channel to publish to automatically. Thechannelinput in operator-workflows is optional — if not provided, it falls back to the charming-actions selection.Suggested approach for charm-ci
Consider one of:
Make
channelinput optional and add branch-based auto-resolution logic (similar to charming-actions/channel) when not provided. This gives callers zero-config multi-track support.Accept a
channel-from-branchboolean that, when true, mapstrack/X→X/edgeand default branch →latest/edge.Document the pattern for callers to add a pre-job that uses
canonical/charming-actions/channeland passes the output to thechannelinput.Option 1 or 2 would provide the smoothest migration path from operator-workflows.
Context
canonical/charming-actions/channelaction: https://github.com/canonical/charming-actions/tree/main/channelcanonical/operator-workflowspublish workflow: https://github.com/canonical/operator-workflows/blob/main/.github/workflows/publish_charm.yaml