Today if you do the following:
local.NewImage("some-image", dockerClient, local.FromBaseImage("some-base-image"))
and some-base-image doesn't exist on the daemon, the image will fail to save on Windows with a cryptic error:
Failed to save image:failed to write image to the following tags: [lifecycle:101f194-dirty: image load 'lifecycle:101f194-dirty'. first error: embedded daemon response: re-exec error: exit status 1: output: ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\49e547ec94502d3e8d1e8de5be79a631f6247fb6fadb57bf288c4c22981a84af: Cannot create a file when that file already exists.] exit status 1
Through experimentation, it seems like the image will actually save successfully on Linux, though I am not sure how this works and why it is different.
pack and lifecycle/tools/image/main.go currently circumvent this issue by pulling the base image prior to initializing the new image.
Outcome
imgutil should produce a helpful error in this scenario.
Today if you do the following:
local.NewImage("some-image", dockerClient, local.FromBaseImage("some-base-image"))and
some-base-imagedoesn't exist on the daemon, the image will fail to save on Windows with a cryptic error:Failed to save image:failed to write image to the following tags: [lifecycle:101f194-dirty: image load 'lifecycle:101f194-dirty'. first error: embedded daemon response: re-exec error: exit status 1: output: ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\49e547ec94502d3e8d1e8de5be79a631f6247fb6fadb57bf288c4c22981a84af: Cannot create a file when that file already exists.] exit status 1Through experimentation, it seems like the image will actually save successfully on Linux, though I am not sure how this works and why it is different.
packand lifecycle/tools/image/main.go currently circumvent this issue by pulling the base image prior to initializing the new image.Outcome
imgutil should produce a helpful error in this scenario.