Is it possible to get the docker build log output from awsx.ecr.Image ?

[anentropic]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I am running pulumi up --verbose=7

It fails with:

  docker:index:Image (30978633-container):
    error: error reading build output: process "/bin/sh -c poetry run ./manage.py collectstatic" did not complete successfully: exit code: 1

I execute the same docker build outside of Pulumi on my machine then the build succeeds.

My problem is I can't work out how to get more details about what the Pulumi resource is doing differently, or what the actual error returned from that command was.

I didn't see any difference in the verbosity of output by adding --verbose=7

Is there a build log somewhere?

It'd be great if it just showed the actual output.

Affected area/feature

awsx.ecr.Image Docker builds

[anentropic]

Usually in Docker Desktop I can see build logs there...

But for some reason the builds that Pulumi/awsx.ecr is doing don't allow that

e.g. here

The successful build is one I ran manually. If I click on that I can see lots of details about the build, including a logs tab.

The ones with http://build-context... names are the Pulumi ones. If I click on that I just see:

[t0yv0]

Hi @anentropic thank you for reporting this problem.

https://www.pulumi.com/registry/packages/docker/api-docs/image/ has some
more info on how Pulumi is building the image.

I have tried to reproduce this and I get close to reproducing it if I edit my Dockerfile to intentionally fail.

For example, if I inject an error in ts-ecr-simple:

[1] anton@anton-mbp-m3> docker build .        ~/code/pulumi-awsx/examples/ts-ecr-simple/app
[+] Building 0.0s (2/2) FINISHED                                                             => [internal] load build definition from Dockerfile                                   0.0s
 => => transferring dockerfile: 89B                                                    0.0s
 => [internal] load .dockerignore                                                      0.0s
 => => transferring context: 2B                                                        0.0s
dockerfile parse error on line 2: unknown instruction: CO (did you mean CMD?)

Pulumi reports parse error on line 2: unknown instruction: CO (did you mean CMD?) in the failure but adding verbose logging does not recover any of the additional messages I can observe from docker build ..

[t0yv0]

Digging a little deeper here, the docker.Image resource is using buildkit to build the image. But there might be a problem with log processing code where some of the information surfaced by buildkit is not being propagated to the user as expected.

I have filed pulumi/pulumi-docker#1268 to investigate if this is the case.

[anentropic]

Thank you for looking into it!

I note that the linked docs say:

Note: We recommend you migrate your images to the more modern Docker Build provider to get the best possible support, features, and performance.

I will also experiment with using that... it's not as straightforward as awsx.ecr.Image but the docs there do show an example of using it to push to ECR.

[t0yv0]

Yes unfortunately you cannot migrate the awsx.ecr.Image resource to the more modern Docker Build provider, this would require a (potentially breaking) change to this repository which our team needs to consider separately.

[anentropic]

FWIW using the recipe here: https://www.pulumi.com/registry/packages/docker-build/

That docker build completes successfully, unlike the awsx.ecr.Image one.

But the nice thing about this docker_build.Image resource is I also get full details of the build in the Docker Desktop app:

(instead of missing digest error)

[t0yv0]

Related: #1349

[anentropic]

one less-nice thing about the docker_build.Image resource is there is no direct way to get the image URI to pass to e.g. Lambda function constructor, whereas the awsx.,ecr.Image resource has an image_uri output

it has a ref property which is the <tag>@<digest>, where the tag is a "fully qualified" tag, i.e. includes the repository URI, but the digest prevents the ref from being used as an image URI

so I had to use this (in Python) to strip the digest:

lambda_image_uri = lambda_image.ref.apply(lambda ref: ref.partition("@")[0])

I was then able to pass this as image_uri to the Lambda Function constructor