Closed BarcoMasile closed 1 week ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1176.
This message was autogenerated
I tried solving this issue by disabling the destructive mode as we discussed, it failed with https://github.com/canonical/kratos-operator/actions/runs/11746211383/job/32798333171#step:5:18
There seem to be 2 reasons for charming actions using the destructive mode enabled by default:
charmcraft pack
completes faster compared to packing in non-destructive mode (less than 15 vs over 25 min on a gh runner)The first issue can be solved by adding a step to install and init lxd:
diff --git a/.github/workflows/publish.yaml b/.github/workflows/publish.yaml
index 79cdf61..1a46aa1 100644
--- a/.github/workflows/publish.yaml
+++ b/.github/workflows/publish.yaml
@@ -53,6 +53,16 @@ jobs:
echo "setting output of destination_channel=$destination_channel"
echo "::set-output name=destination_channel::$destination_channel"
+ # Required to charmcraft pack in non-destructive mode
+ - name: Install and initialize lxd
+ id: install-lxd
+ run: |
+ /usr/bin/sudo snap install lxd --channel=latest/stable
+ /usr/bin/sudo lxd waitready
+ /usr/bin/sudo lxd init --auto
+ /usr/bin/sudo iptables -F FORWARD
+ /usr/bin/sudo iptables -P FORWARD ACCEPT
+
- name: Upload charm to charmhub
The fact it takes longer time to build is not a big inconvenience given that it's only run on push.
We can accept the above and add the lxd step or fall back to run on 22.04, @nsklikas @BarcoMasile @shipperizer wdyt?
My 2 cents on this is: if it works let's keep this solution, have a "test run" on a more populare repo (one with more PRs), and then re-assess after a pulse.
Fixed by https://github.com/canonical/kratos-operator/pull/298, new revision was published: https://charmhub.io/kratos?channel=latest/edge
Enhancement Proposal
Description
Right now charmcraft.yaml needs to use a different syntax to make charm work on Ubuntu 24.04 (see https://github.com/canonical/charmcraft/issues/1789, which also applies to regular charms, not only subordinates).
We need to find a way to make charm definition work without breaking retro compatibility for our charms, be it a CI refactor or a unified solution.