libcnb-tests: Integration tests failing on main when run locally on macOS

[edmorley]

I would presume this is due to the recent update to Docker for Desktop for macOS, or else my upgrade to macOS 14.1 (which included some Rosetta changes).

failures:

---- app_dir_preprocessor stdout ----
thread 'app_dir_preprocessor' panicked at libcnb-test/tests/integration_test.rs:189:13:
assertion `left == right` failed
  left: ".\n./.cache\n./.cache/rosetta\n./Procfile\n./subdir1\n./subdir1/file2.txt\n./subdir1/subdir2\n./subdir1/subdir2/subdir3\n./subdir1/subdir2/subdir3/file3.txt\n"
 right: ".\n./Procfile\n./subdir1\n./subdir1/file2.txt\n./subdir1/subdir2\n./subdir1/subdir2/subdir3\n./subdir1/subdir2/subdir3/file3.txt\n"

---- expose_port_invalid_port stdout ----
thread 'expose_port_invalid_port' panicked at libcnb-test/tests/integration_test.rs:489:17:
internal error: entered unreachable code: The test should fail before the ContainerContext is invoked.
note: panic did not contain expected string
      panic message: `"internal error: entered unreachable code: The test should fail before the ContainerContext is invoked."`,
 expected substring: `"Port `0' not valid"`

It looks like Docker's Rosetta implementation now leaves cache files in .cache/rosetta which is breaking the directory listing assertion here:

libcnb.rs/libcnb-test/tests/integration_test.rs

Lines 177 to 189 in cdd2eb4

	let expected_directory_listing = indoc! {"
	.
	./Procfile
	./subdir1
	./subdir1/file2.txt
	./subdir1/subdir2
	./subdir1/subdir2/subdir3
	./subdir1/subdir2/subdir3/file3.txt
	"};
	let log_output = context.run_shell_command("find . | sort");
	assert_empty!(log_output.stderr);
	assert_eq!(log_output.stdout, expected_directory_listing);

As for the docker port test - it seems the Docker daemon now accepts port 0 when it didn't before.

Previously the Docker daemon would return this error:

docker: Error response from daemon: driver failed programming external connectivity on endpoint libcnbtest_yjlrqgjxvpgr (e94262e0ff239906824e7dd76c4637db66de1948874b9e0a58b5ae1771ce66bb):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 32779 -j DNAT --to-destination 172.17.0.2:0 ! -i docker0: iptables v1.8.7 (nf_tables): Port `0' not valid

Try `iptables -h' or 'iptables --help' for more information.
 (exit status 2)).

This test was one I wrote to be thorough, but looking at it again now it seems pretty redundant (it's testing a slightly contrived scenario, and failures starting containers are already tested in several other ways), so I think we should just remove the test.

GUS-W-14395756.

[edmorley]

It's worth noting that neither of these failures were made worse by the switch from Bollard to the Docker CLI, since that only changed the Docker client, whereas both of these failures were due to a new version of the daemon (and/or VM components that Docker for Desktop uses to run the daemon).

[edmorley]

It looks like Docker's Rosetta implementation now leaves cache files in .cache/rosetta

So I presume this is happening since Rosetta puts the cache in $HOME at runtime, and currently $HOME is set to the app dir at runtime:
https://github.com/heroku/stack-images/blob/a3ca440ac050df03b99909d808c152093bdd0f96/heroku-22-cnb/Dockerfile#L10

IMO longer term we should consider changing $HOME to something other than the app-dir. See also:
buildpacks/spec#186