When platform api >= 0.9, analyzer accepts -skip-layers and -launch-cache

[natalieparellano]

Fixes #1390

Before: slow performance when restoring SBOM layer from previous image (using a daemon and untrusted builder)

Released pack

$  time pack build test-launch-cache -B test-builder -v
Builder test-builder is untrusted
...
[analyzer] Restoring data for SBOM from previous image
[analyzer] Retrieving previous image SBOM layer for "sha256:aa138e6bbe1f1bfd301953ea3ffc563b618f765e337447fe5b030a9f1b95c34f" <-- build hangs for a few seconds here
...
Successfully built image test-launch-cache

real	0m27.861s
user	0m0.107s
sys	0m0.105s

After: -launch-cache makes the build faster

Dev pack

$  time ~/workspace/pack/out/pack build test-launch-cache -B test-builder -v
Builder test-builder is untrusted
...
[analyzer] Restoring data for SBOM from previous image
[analyzer] Retrieving previous image SBOM layer for "sha256:b3f1c8a10edd5bde715cd7c3e52a8978999cbdcacf00857fc77ddc46ee031751" <-- build breezes through this part
...
Successfully built image test-launch-cache

real	0m19.673s
user	0m0.119s
sys	0m0.117s

Before: --clear-cache when passed doesn't actually skip SBOM layer restoration (though the layer is ignored)

$ pack build test-launch-cache -B test-builder -v --clear-cache
Builder test-builder is untrusted
...
[analyzer] Restoring data for SBOM from previous image <-- we're still restoring data from the previous image despite --clear-cache
[analyzer] Retrieving previous image SBOM layer for "sha256:09e68295ca186849d7a6fbbfe041139282786ad6b9a10760ed4e09ae18c49328"
...

After: -skip-layers completely skips this step

$ ~/workspace/pack/out/pack build test-launch-cache -B test-builder -v --clear-cache
Builder test-builder is untrusted
...
===> ANALYZING
[analyzer] Analyzing image "e269de03f16bdf31122c90e02ffd05d3b4269d8ccc41abb8916aa3c66901b591"
[analyzer] Analyzing image "497ee92d82e944a5b4a9e2d9802e9261bf65cf509d07096dbd83a909c98baadd"
===> DETECTING

Documentation

• Should this change be documented?
  • Yes, see #___
  • No

Related

Resolves #1390

[natalieparellano]

It's weird... the dev version of pack from make build builds successfully (as shown above) but the acceptance tests fail with:

     |         [analyzer] ERROR: failed to create launch cache: initializing staging directory '/launch-cache/staging': mkdir /launch-cache/staging: permission denied

buildpacks/lifecycle#847 fixes this... but TBH IDK why it's necessary. There must be some difference in how pack is creating volumes "for real" and when running the acceptance tests.

[natalieparellano]

I guess we should block this on buildpacks/lifecycle#847

[jromero]

It's weird... the dev version of pack from make build builds successfully (as shown above) but the acceptance tests fail with:

     |         [analyzer] ERROR: failed to create launch cache: initializing staging directory '/launch-cache/staging': mkdir /launch-cache/staging: permission denied

buildpacks/lifecycle#847 fixes this... but TBH IDK why it's necessary. There must be some difference in how pack is creating volumes "for real" and when running the acceptance tests.

Hmmm... I'm not sure I would say that. Not looking so deep into the problem, I am more leaning towards this being an issue for linux since that is where they are mostly failing. IIRC, in linux some permissions/ownership between host and container are linked. Don't quote me on that but I'm willing to place my bets more in that direction.

Didn't read all of this but it seems to validate some of my thinking and why I think this would work with your fix: https://blog.gougousis.net/file-permissions-the-painful-side-of-docker/

Let me remind you here that file permissions on bind mounts are shared between the host and the containers (of course, there are also a few other ways that file permissions are transferred between host and containers).

[codecov]

Codecov Report

Merging #1417 (28e5691) into main (98698c4) will increase coverage by 0.01%.
The diff coverage is 88.24%.

@@            Coverage Diff             @@
##             main    #1417      +/-   ##
==========================================
+ Coverage   81.27%   81.27%   +0.01%     
==========================================
  Files         151      151              
  Lines        9760     9764       +4     
==========================================
+ Hits         7931     7935       +4     
  Misses       1352     1352              
  Partials      477      477              

Flag	Coverage Δ
os_linux	80.02% <88.24%> (+0.07%)	⬆️
os_macos	77.44% <88.24%> (+0.01%)	⬆️
os_windows	81.15% <88.24%> (+0.04%)	⬆️
unit	81.27% <88.24%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[natalieparellano]

I don't know why Codecov is unhappy - it's highlighting lines that I didn't change...

IDK what to say. The patch coverage is 88% which is higher than the project average but it still decreases overall coverage? Something doesn't add up.

[samj1912]

Thanks for this!