-
Notifications
You must be signed in to change notification settings - Fork 8
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
libcnb-test: Images not cleaned up when pack build
unexpectedly suceeeds
#586
Labels
Comments
colincasey
added a commit
that referenced
this issue
Jul 5, 2023
Moves the creation of the `TestContext` to before the invocation of `run_pack_command` so that the context will be cleaned up regardless of the outcome. @fixes #586
colincasey
added a commit
that referenced
this issue
Jul 5, 2023
Moves the creation of the `TestContext` to before the invocation of `run_pack_command` so that the context will be cleaned up regardless of the outcome. @fixes #586
edmorley
added a commit
that referenced
this issue
Aug 8, 2023
#625) Previously, if a test with an expected result of `PackResult::Failure` unexpectedly succeeded, the built app image was left behind since cleanup was only performed in `TestContext::Drop` (and in this scenario, a `TestContext` is never created in the first place). Now the app image is correctly cleaned up. Fixes #586. Closes #588. GUS-W-13903181.
edmorley
added a commit
that referenced
this issue
Nov 16, 2023
At the end of each test libcnb-test is meant to clean up any Docker resources that were created during the test. However, this functionality currently isn't tested, and we've found several cases where cleanup wasn't occurring as expected: - #586 - #570 - #737 We could try and add a Rust integration test or two to check that cleanup works in the common case, however, as seen by the issues above, it's often in the edge cases where resource cleanup wasn't working. In addition, testing cleanup during an individual test is hard, since other tests will be running at the same time, so we'd have to check for individual image or container names, which would miss cases like #570. As such, it's much easier for us to instead just check that there are zero unexpected resources left behind at the end of the existing entire libcnb-test test suite. For now, two of the checks don't cause CI to fail, since the fixes for the cleanup implementations have not yet landed. GUS-W-14502524.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When libcnb-test invokes
pack build
, it passes an explicit Docker image name that is thendocker rmi
'd once the associatedTestContext
struct is dropped:libcnb.rs/libcnb-test/src/test_context.rs
Lines 248 to 264 in d9f0bc1
However, there is one scenario where this clean-up is not taking place: When
.expected_pack_result(PackResult::Failure)
has been used, and then thepack build
unexpectedly succeeds.For example, during this the
unexpected_pack_success
testcase:libcnb.rs/libcnb-test/tests/integration_test.rs
Lines 161 to 174 in d9f0bc1
In this scenario, the panic occurs in
run_pack_command
before theTestContext
has been created:libcnb.rs/libcnb-test/src/pack.rs
Lines 179 to 214 in d9f0bc1
This means there is no
TestContext
to be dropped, so no remove image command is invoked.This causes a leak of one image each time the
libcnb.rs
repo's integration tests are run, eg:GUS-W-13903181.
The text was updated successfully, but these errors were encountered: