`charmcraft upload` should be able to take several `*.charm` files at once

[sed-i]

What needs to get done

There seems to be an inconsistency in how charmcraft upload creates "artifacts" on charmhub.io.

One of our o11y charms, grafana-agent, is a subordinate charm, so we need it to run on 20.04 and 22.04. We can no longer produces a single charm file (build-on: [22.04]; run-on: [20.04, 22.04]) because the 22.04-built charm does not run on 20.04 (libssl.so.3 isn't there in 20.04). Splitting bases -- having 1:1 match between build-on and run-on -- works.

My question: how do I charmcraft upload two separate *.charm files so they appear "all in one" on charmhub?

Use case 1: multiple run-on for the same build-on

bases:
  - build-on:
    - name: "ubuntu"
      channel: "22.04"
      architectures: ["amd64"]
    run-on:
    - name: "ubuntu"
      channel: "22.04"
      architectures: ["amd64"]
    - name: "ubuntu"
      channel: "20.04"
      architectures: ["amd64"]

Output is a single file:

• grafana-agent_ubuntu-22.04-amd64_ubuntu-20.04-amd64.charm

Charmhub artifacts are multiple series in the same channel/revision:

Use case 2: 1-to-1 match between run-on and build-on

bases:
  - build-on:
    - name: "ubuntu"
      channel: "20.04"
      architectures: ["amd64"]
    run-on:
    - name: "ubuntu"
      channel: "20.04"
      architectures: ["amd64"]
  - build-on:
    - name: "ubuntu"
      channel: "22.04"
      architectures: ["amd64"]
    run-on:
    - name: "ubuntu"
      channel: "22.04"
      architectures: ["amd64"]

Output is two files:

• grafana-agent_ubuntu-20.04-amd64.charm
• grafana-agent_ubuntu-22.04-amd64.charm

But here it seems impossible to upload both into the same charmhub "artifact":

• I have to upload each file separately, each getting its own revision number.
• Seems like I would have to have a charmhub track per series?

Why it needs to get done

To maintain consistency in how charmhub handles multiseries artifacts between use cases 1 and 2 above.

[sed-i]

@sergiusens our grafana-agent machine charm is blocked by this. Is this something you imagine could be addressed in the near future?

[sergiusens]

@sed-i the only way I can think of to operate on these two different charm revisions is to make them part of a build-set (like we have for snaps for different architectures) @antonpkazakov do we have the concept of a build-set for Charmhub?

[wgrant]

Build sets in the Snap Store world are syntactic sugar for release operations; they don't actually enable any new functionality, just make publisher operations quicker and less error-prone. Charmhub's support for charms of different "bases" (OS, series and architecture) is akin to the Snap Store's architecture support, and is fully implemented and working.

If you upload the 20.04 and 22.04 charms above, release them both to latest/stable, and run charmcraft status grafana-agent, you'll see a bunch of rows with a "Base" column showing that 20.04 and 22.04 each get the corresponding revision. Juju deployments targeting a specific series or architecture will pick the right revision. The charmhub.io web UI doesn't easily show this, because it currently only allows filtering in the architecture dimension of base, not the OS or series, but that's purely a limitation of the presentation there.

[sed-i]

Thanks for the details @wgrant! @taurus-forever, iirc, you were doing with mysql exactly what @wgrant described above. Just curious if you really do and how it works for you.

[sergiusens]

I guess I got confused by the report and got into my head of it being about making release operations simpler. It seems that is not the case and that this is similar to what @taurus-forever reported

[sed-i]

Thanks everyone for the details! Pans out that uploading the *.charm files separately and letting juju figure out which revision to use is the correct approach. Closing.