Frontend charm integration tests fix with a self hosted runner - #54
Conversation
…n blocked status (more scenarios needed to actually relate the frontend to the backend).
…ger the integration tests with.
… action is required.
…state where relation is not yet connected. Simplified the charm logic, no _stored state needed (fetching the hostname and port from the relation's application data bag).
Let's try with the microk8s version and libpyjuju < 3.1 that seems to work for rout53-acme-operator where the integration test pipeline is pulled from
…rver into integration-test-fix
mz2
changed the title
…:canonical/test_observer into integration-test-fix-with-hosted-runners
| @@ -1 +1,2 @@ | |||
| ops >= 2.2.0 | |||
| ops >= 2.8.0 | |||
| macaroonbakery==1.3.2 No newline at end of file | |||
There was a problem hiding this comment.
Added as a workaround to https://github.com/canonical/test_observer/actions/runs/7142353669/job/19451476954 as instructed at https://chat.canonical.com/canonical/pl/9xzxm61rgtry5d7sfx9xz7ryyc
| deps = | ||
| pytest | ||
| juju | ||
| juju<=3.2 |
There was a problem hiding this comment.
This is intentionally <= 3.2 as opposed to for example >= 2.9 as is set in the charm metadata: the integration test environment is set to be 3.x (2.9 was not really behaving in the github runner context, which is possible to go investigate but probably not worth our while unless we get stuck in production 2.9 for a long time unexpectedly).
| provider: microk8s | ||
| uses: actions/checkout@v4 | ||
| - name: Set up microk8s | ||
| uses: canonical/certification-github-workflows/.github/actions/microk8s-setup@microk8s-setup-action |
There was a problem hiding this comment.
The setup steps turned out to be more extensive on self hosted runners, and since this is all repetitive boilerplate that becomes relevant again when we want to integration test any other charmed part of our stack, I moved the whole lot to a reusable composite action. Same story below re: the archive-charm-testing-artifacts
…R review has been submitted
…es to resources under frontend/charm
| terraform { | ||
| required_providers { | ||
| juju = { | ||
| version = "~> 0.7.0" |
There was a problem hiding this comment.
The changes below showed up as necessary when the provider was updated: the series was deprecated (and base which replaces is similarly nonsensical for k8s charms) => series removed below.
There was a problem hiding this comment.
This change is not strictly speaking necessary for the charm integration tests (though it was my intention to also test out in succession also that the terraform plan continues to be able to spin a new environment up that stabilises in an all-ready state).
There was a problem hiding this comment.
can we do this on PS5 though? as in can we use tf provider for juju version 0.10.0?
There was a problem hiding this comment.
I think this should indeed Just Work, in that the next time you deploy using this plan, it will upgrade the provider to the latest version that is described here. Deploying to staging will confirm that safely, I'd say.
omar-selo
left a comment
omar-selo
left a comment
There was a problem hiding this comment.
It's amazing that you got it to work! finally this has been annoying for a long time
| terraform { | ||
| required_providers { | ||
| juju = { | ||
| version = "~> 0.7.0" |
There was a problem hiding this comment.
can we do this on PS5 though? as in can we use tf provider for juju version 0.10.0?
|
Superseded by #80 |
4 participants
Integration tests for the frontend charm now actually work also on GitHub!
The workflow looks to be stable, with a dozen passes witnessed today.
It does however take ~10mins to run and I figured we would therefore not start running it on every commit to every branch (6+ mins of the time is taken by the microk8s setup -- we can drop this in a big way with custom images used for the CI runs when that becomes available). It runs on:
./frontend/charm(the integration tests can capture failures also in resources outside that directory, hence the rule above also).The workflow was refactored to reuse two now introduced reusable composite actions in https://github.com/canonical/certification-github-workflows (the first PR to that repo should be reviewed and merged first before this goes in).
NOTE! When squashing this into main, please edit the commit message heavily down in volume since this contains a few months worth of desperate debugging attempts of these integration tests that continued to work locally just fine but failed to be executed specifically on GitHub up until now. I have simplified the version history with some squashing but since there are several merge commits there I didn't want to do anything more drastic than that.