-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
c115fae
to
fb4817a
Compare
…:canonical/test_observer into integration-test-fix-with-hosted-runners
frontend/charm/requirements.txt
Outdated
@@ -1 +1,2 @@ | |||
ops >= 2.2.0 | |||
ops >= 2.8.0 | |||
macaroonbakery==1.3.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -66,7 +66,7 @@ commands = | |||
description = Run integration tests | |||
deps = | |||
pytest | |||
juju | |||
juju<=3.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -1,7 +1,7 @@ | |||
terraform { | |||
required_providers { | |||
juju = { | |||
version = "~> 0.7.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's amazing that you got it to work! finally this has been annoying for a long time
@@ -1,7 +1,7 @@ | |||
terraform { | |||
required_providers { | |||
juju = { | |||
version = "~> 0.7.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we do this on PS5 though? as in can we use tf provider for juju version 0.10.0
?
Superseded by #80 |
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.