search

canonical / data-platform-workflows

Reusable GitHub Actions workflows used by the Data Platform team
Apache License 2.0
3 stars 9 forks source link

[RFE] Include SNAP revision that was used at given charm release #160

Open phvalguima opened 3 months ago

phvalguima commented 3 months ago

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".

github-actions[bot] commented 3 months ago

https://warthogs.atlassian.net/browse/DPE-3922

carlcsaposs-canonical commented 3 months ago

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

carlcsaposs-canonical commented 3 months ago

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