ci: disable non-essential checks that need adjustments to work with a Python 3.10 minimum #1878
Conversation
| run: pip install tox~=4.2 uv~=0.6 | ||
|
|
||
| - name: Update 'ops' and 'ops-scenario' dependencies in test charm to latest | ||
| if: ${{ !(matrix.disabled) }} |
There was a problem hiding this comment.
Is it possible/worth using this pattern in charmcraft-pack.yaml too?
There was a problem hiding this comment.
I'm not sure. We added it to the third-party charms because sometimes they break out of our control (something in the upstream changes) and we wanted a way to skip them while still letting the pin update action do its magic (previously, we just commented items out).
Not in this PR, though.
I think in general if we want to check packing, we should do that with 1+ charms that are in our repo. We're already doing this in the smoke tests anyway, we could just promote those to be a release check, or re-use those, or use one/more of the example charms, etc. If we do that then we shouldn't need to disable them, because if they break, that's our fault.
| # - charm-repo: jnsgruk/hello-kubecon | ||
| # commit: eb3225860cc7db0e071d0ea6cd4a01b47e66b1e5 # 2025-03-27T12:05:21Z |
There was a problem hiding this comment.
+1 from me on removing this entire file.
There was a problem hiding this comment.
I'd prefer to keep this change minimal, just acknowledging explicitly that we understand why it's not working and that we're ok with that for the 3.0 release, and then dealing with the longer term fixes before the next release, but in the other ticket for it.
I think commenting it out is a clearer statement than removing the entire workflow. We aren't intending to stop testing packing, we're just going to update what we pack.
| # - charm-repo: jnsgruk/hello-kubecon | ||
| # commit: eb3225860cc7db0e071d0ea6cd4a01b47e66b1e5 # 2025-03-27T12:05:21Z |
There was a problem hiding this comment.
+1 from me on removing this entire file.
Co-authored-by: Dima Tisnek <dimaqq@gmail.com>
4 participants
To be resolved by:
We're confident that nothing will have changed in Ops that breaks these, and they aren't required to merge, but we should get them green (by explicitly disabling them, as here) before we do the next release.