-
Notifications
You must be signed in to change notification settings - Fork 503
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
test: pack test charms #18151
test: pack test charms #18151
Conversation
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.
We shouldn't be committing binaries to the code base.
Please prepare for Charmcraft 3.0 and ubuntu 24.04 where each Charmcraft.yaml can have only 1 base. One issue to solve will to be to determine which architecture to build for the test run.
Deploying a charm from an unpacked directory is no longer supported in 4.0. Hence, when using local charms in testing, we need to pack them first inside the test. - I added a test utility function `pack_charm` which uses Charmcraft to pack the charm at the given path, and returns a glob that can be provided to `juju deploy` to deploy the packed charm. - I have added/updated the `charmcraft.yaml` in several testing charms to be compatible with the new Charmcraft changes in 3.0. - I have added `charmcraft` to the checked dependencies for those tests which require charms to be packed.
dacae14
to
ded0fe2
Compare
/build |
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.
Looks good, just a question about errors in the tests
@@ -22,7 +22,8 @@ run_juju_bind() { | |||
configure_multi_nic_netplan "$juju_machine_id" "$hotplug_iface" | |||
|
|||
# Deploy test charm to dual-nic machine | |||
juju deploy ./testcharms/charms/space-defender --bind "defend-a=alpha defend-b=isolated" --to "${juju_machine_id}" | |||
# shellcheck disable=SC2046 |
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.
What happens with the output of pack_charm here if it fails for some reason? Does doing it in line like this hide the error in any way? If it does we should do it as a separate line cuz it'll make the tests a lot easier to debug
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'm not sure, can you test it?
|
||
charmcraft pack -p "$CHARM_DIR" | ||
echo "./${CHARM_NAME}_*.charm" | ||
} |
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 would be really great if you could cache charms on the host file system. That way we can save a bunch of time when running tests locally
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.
Charmcraft internally caches a lot of stuff, so packing charms is way quicker on subsequent runs, like 15 seconds.
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.
Yeah fair enough. It would still be nice though!
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.
@barrettj12 is correct here.
Do we know if it uses lxd by default, if not, it might be worth testing that using charmcraft pack --use-lxd
. If it is, just ignore me :)
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.
Yes, it uses LXD by default. You have to pass --destructive-mode
to build on the host.
# shellcheck disable=SC2046 | ||
juju deploy $(pack_charm ./testcharms/charms/lxd-profile) | ||
# shellcheck disable=SC2046 | ||
juju deploy $(pack_charm ./testcharms/charms/lxd-profile-subordinate) |
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'd rather we quote properly than add shellcheck exceptions
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.
Quoting doesn't work because the output of pack_charm
is a glob (e.g. lxd-profile_*.charm
). If it is quoted, it will be treated like a literal file name, which is not what we want here.
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.
Ah I see
charm=./tests/suites/deploy/charms/lxd-profile-alt | ||
juju deploy "${charm}" --to lxd | ||
charm=$(pack_charm ./tests/suites/deploy/charms/lxd-profile-alt) | ||
juju deploy ${charm} --to lxd |
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.
Why remove quotes?
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.
See above reply.
#18211 The local charm integration tests relied on the ntp charm which was not up to date with the latest charm requrements and caused an error on deploy. It was held in launchpad and not under our control. Switch to using the ubuntu-plus charm instead from test testcharms directory. Note that these tests deploy from directory so will not work in 4.0. They will need to be updated or maybe even just deleted when the patch is merged up. If they are kept they should use the work added in #18151. BONUS COMMIT: add big V verbose option <!-- The PR title should match: <type>(optional <scope>): <description>. Please also ensure all commits in this PR comply with our conventional commits specification: https://docs.google.com/document/d/1SYUo9G7qZ_jdoVXpUVamS5VCgHmtZ0QA-wZxKoMS-C0 --> <!-- Why this change is needed and what it does. --> ## Checklist <!-- If an item is not applicable, use `~strikethrough~`. --> - [x] Code style: imports ordered, good names, simple structure, etc - [x] Comments saying why design decisions were made - [x] Go unit tests, with comments saying what you're testing - [x] [Integration tests](https://github.com/juju/juju/tree/main/tests), with comments saying what you're testing - [ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages ## QA steps ``` ./main.sh -v cli ```
|
||
charmcraft pack -p "$CHARM_DIR" | ||
echo "./${CHARM_NAME}_*.charm" | ||
} |
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.
@barrettj12 is correct here.
Do we know if it uses lxd by default, if not, it might be worth testing that using charmcraft pack --use-lxd
. If it is, just ignore me :)
echo "==> Checking for dependencies" | ||
check_dependencies charmcraft |
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.
👍
local CHARM_DIR=$1 | ||
CHARM_NAME=$(basename "$CHARM_DIR") | ||
|
||
charmcraft pack -p "$CHARM_DIR" |
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.
If you want to see the messages and we want to ensure it fails correctly, even when inline you could do the following.
charmcraft pack -p "$CHARM_DIR" | |
set -eux | |
charmcraft pack -p "$CHARM_DIR" | |
set_verbosity |
Note: we should ensure that the Jenkin runners have charmcraft installed. |
/merge |
Deploying a charm from an unpacked directory is no longer supported in 4.0. Hence, when using local charms in testing, we need to pack them first inside the test.
pack_charm
which uses Charmcraft to pack the charm at the given path, and returns a glob that can be provided tojuju deploy
to deploy the packed charm.charmcraft.yaml
in several testing charms to be compatible with the new Charmcraft changes in 3.0.charmcraft
to the checked dependencies for those tests which require charms to be packed.Checklist
[ ] Go unit tests, with comments saying what you're testing[ ] doc.go added or updated in changed packagesQA steps
Run the following test suites: deploy, hooks, relations, sidecar, spaces_ec2, storage.
Many of these tests will not pass due to other issues, but at least we should not see the following error:
Links
Jira card: JUJU-6825