canonical/charming-actions

[upload-charm] always uses the latest revision of the resource

Closed this issue · 6 comments

nsklikas commented

Bug Description

The upload-charm action:

  1. pushes a resource to charmhub (https://github.com/canonical/charming-actions/blob/main/src/services/charmcraft/charmcraft.ts#L54)
  2. Pulls all the resource's revisions and uses the latest (https://github.com/canonical/charming-actions/blob/main/src/services/charmcraft/charmcraft.ts#L56)

Perhaps this was caused by a (rogue?) charmhub API change, but if you push a resource to charmhub that already exists, that resource does not get a new revision. This wasn't always the case.

This means that if a charm will always use the latest resource version and not the one defined in the metadata.

Instead uploadResource should run something like:
charmcraft upload-resource <charm-name> oci-image --image <sha> --format json --verbosity brief

And parse the output to get the revision, the call to list all the revisions is not needed.

To Reproduce

Downgrade the image in a charm's metadata

Environment

github?

Relevant log output

https://github.com/canonical/kratos-operator/actions/runs/8919940662/job/24497519038 (the resource uploaded with the charm is a difference version from the one defined in the metadata)

Additional context

No response

orfeas-k commented

Great catch @nsklikas ! This has bitten us as well and we were really wondering why this happened. This happened when we updated the charm's resource to a previously used resource (in order to work around a juju bug temporarily) and while the publish succeeded, silently it kept using the previous image, since, as you highlight, this was the latest resource version ( the CI run)

  • 👍1
DnPlas commented

It looks like this is more a charmcraft behaviour rather than the action's. If you manually try to create a new revision of the resource that was already uploaded, charmcraft will just not allow it.

EDIT: I meant to say charmhub, it won't allow to upload a resource that was already uploaded, so there will not be a new revision of it.

nsklikas commented

It looks like this is more a charmcraft behaviour rather than the action's

Why? AFAICT charhmcraft provides you with all the info you need to do this properly.

The charmhub behavior changed some time in the past. It used to be that whenever you uploaded an image it would get a new revision, regardless if it was already uploaded. At the time the charmhub team refused to fix it, claiming it that this was the intended behavior. Now it looks like they have changed without any warning (?).

But this is the action's problem, I tried to explain it in the description. If you try to upload the same image multiple times, you will always get the same revision
image

The action must parse parse the charmcraft output and use the revision number that is in the command's output, rather that always using the latest revision.

Am I missing something?

  • 👍1
carlcsaposs-canonical commented

fwiw, data-platform-workflows release_charm.yaml does not seem to be affected

here's how it works, perhaps a similar approach would help here: https://github.com/canonical/data-platform-workflows/blob/58f047f7eebbde23770e7058d3f62f88ce7fe0dd/python/cli/data_platform_workflows_cli/craft_tools/release.py#L182

(or, if there's interest in moving the charm/snap/rock workflows in data-platform-workflows into a shared repo—again, happy to help with that)

  • 👍1
carlcsaposs-canonical commented

looking at our release history, this change appears to have happened on charmcraft/charmhub between 2023-10-28 and 2023-11-01

incrementing every release in 2023-10:
https://github.com/canonical/postgresql-k8s-operator/releases/tag/rev159
https://github.com/canonical/postgresql-k8s-operator/releases/tag/rev160
https://github.com/canonical/postgresql-k8s-operator/releases/tag/rev161

2023-11-01 release doesn't increment:
https://github.com/canonical/postgresql-k8s-operator/releases/tag/rev165

  • 👍1
carlcsaposs-canonical commented

and downloading charm rev 165 and 161 & inspecting manifest.yaml shows

# ubuntu@j34-1:~$ cat 165/manifest.yaml 
analysis:
  attributes:
  - name: language
    result: python
  - name: framework
    result: operator
bases:
- architectures:
  - amd64
  channel: '22.04'
  name: ubuntu
charmcraft-started-at: '2023-10-31T22:37:44.128831Z'
charmcraft-version: 2.4.1
# ubuntu@j34-1:~$ cat 161/manifest.yaml 
analysis:
  attributes:
  - name: language
    result: python
  - name: framework
    result: operator
bases:
- architectures:
  - amd64
  channel: '22.04'
  name: ubuntu
charmcraft-started-at: '2023-10-28T13:59:41.367818Z'
charmcraft-version: 2.4.1

so change was probably on charmhub, not charmcraft

  • 👍1