You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To also contain the snap revision that was used for a given deployment. This way a given user, e.g. support teams, can quickly relate charm <> snap. I believe we can pull that information at the end of integration testing.
We should also should check if the snap is set as "held".
The text was updated successfully, but these errors were encountered:
The snap revision is controlled by the charm code & not in a standardized format
I have some concerns with separation of responsibilities/creating "magical" implicit dependencies
Example of complexity: how do you handle snap revisions on different architectures? Different charms can handle that differently
To me, this seems like something that (if implemented) should be implemented at the charmcraft level so it can be standardized across all charms & made consistent with OCI image revisions on k8s charms
For documentation: Right now, the current approach is to get the commit that matches the revision (from github release or git tag) and then browse the source code for the snap revision
Can we extend the text in, for example: https://github.com/canonical/mysql-operator/releases/tag/rev220
To also contain the snap revision that was used for a given deployment. This way a given user, e.g. support teams, can quickly relate charm <> snap. I believe we can pull that information at the end of integration testing.
We should also should check if the snap is set as "held".
The text was updated successfully, but these errors were encountered: