You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#516 disabled the inline image deletion from integration tests, as it would sometimes corrupt the build cache. Test images will just pile up now- not a problem for CI, but definitely a problem for local execution.
We don't want to just blindly prune or otherwise blast images that our test might not have created (at least not without also marking such tests as destructive), but the distributed nature of pytest-xdist complicates the necessary bookkeeping to defer explicit image deletion until the end of the session, since only the workers know what images they created, but the main session teardown hook runs in the main controller long after the required data is lost.
One idea:
Have delete_image record the image names in a per-runtime set that's tied to a session-scoped fixture. At fixture teardown, merely append the data to well-known filenames in the session tempdir (using a lockfile/mutex or atomic write, since multiple workers may hit it at once). Then have the main session or unload hook read all the names for each runtime into a set (as some may be duplicated across workers) and best-effort delete all the images in those files, producing warnings if there are problems.
The text was updated successfully, but these errors were encountered:
#516 disabled the inline image deletion from integration tests, as it would sometimes corrupt the build cache. Test images will just pile up now- not a problem for CI, but definitely a problem for local execution.
We don't want to just blindly
prune
or otherwise blast images that our test might not have created (at least not without also marking such tests asdestructive
), but the distributed nature ofpytest-xdist
complicates the necessary bookkeeping to defer explicit image deletion until the end of the session, since only the workers know what images they created, but the main session teardown hook runs in the main controller long after the required data is lost.One idea:
delete_image
record the image names in a per-runtimeset
that's tied to a session-scoped fixture. At fixture teardown, merely append the data to well-known filenames in the session tempdir (using a lockfile/mutex or atomic write, since multiple workers may hit it at once). Then have the main session or unload hook read all the names for each runtime into a set (as some may be duplicated across workers) and best-effort delete all the images in those files, producing warnings if there are problems.The text was updated successfully, but these errors were encountered: