Update default bundle size limit to fit slightly larger content. Longer term we'll want to refactor these tests so they don't start failing to seemingly unrelated upstream changes, but for now this buys us time to work on other, more important things. (#7414)
What happened to cause this: The test_WindowsAndMac_BundlesAndBundleSettings_EquivalentOutput test bundles the same content in two different ways, with the final intention to compare and verify the results are the same. It's bundling up the level levels\testdependencieslevel\testdependencieslevel.spawnable Along the way, it verifies the bundles it gets are what it expects. One of the bundle settings it uses is a relatively small maximum bundle size of 5 mib. Note that when we use a maximum bundle size, it's not a hard limit, it's just when we go to create a new bundle, if the current bundle size + next file would make the bundle too big, it starts a new bundle. This means you can have bundles go over the bundle size in the case where one file is larger than the bundle size limit. Somehow, one of the files referenced from this bundle ( goegap_4k_skyboxcm.exr.streamingimage ) is now 24 MB, which is larger than the default bundle size originally used, which is why the test fails, it goes to examine the contents of the second pak file of the first bundle, and it's larger than the maximum bundle size. That's why the test is failing. Changing this to 30 mib causes this test to continue to pass. Signed-off-by: AMZN-stankowi <4838196+AMZN-stankowi@users.noreply.github.com>monroegm-disable-blank-issue-2
parent
adb598445f
commit
38a34d811d
Loading…
Reference in New Issue