Option to re-enable docker build on preview

[NakulK48]

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 noted in the v4.0.0 changelog that running pulumi preview on a stack containing a docker.Image will no longer build the image https://github.com/pulumi/pulumi-docker/releases/tag/v4.0.0

This is advertised as a feature, but we actually find it quite useful to have a verification of the correctness of a dockerfile before applying the update (e.g. to run in CI on every commit in a PR). Is it possible to have a flag that re-enables preview building, or is there a better approach to validating the dockerfile pre-release?

Affected area/feature

Something like:

const image = new docker.Image(deploymentName, {
  build: {
    context: "..",
    dockerfile: "../docker/Dockerfile",
  },
  imageName: repo.repositoryUrl,
  localImageName: deploymentName,
  buildOnPreview: true
});

[AaronFriel]

@NakulK48 Thanks for flagging this as a feature request! Could you add an example of how a user would use this flag to your issue?

[jamie1911]

+1 for this.

As someone who approves the PRs developers and other members send my way, I would like to see the successful build process before approving the PR.

We use automation that does the pulumi preview in the PR and we check the pipelines to see what changes/etc have been made and everything runs successfully, before approving the PR.

Now in its >= 4.0.0 state, someone can add a bug into the Dockerfile, someone will approve the PR, which succeeded via pulumi preview, and now once it gets into pulumi up, the docker build fails and the entire pipeline is stopped.

In terms of speed up, we use docker cache on the hosts that run the pulumi previews, so a pulumi preview will generate the docker cache for the first time, when pulumi up runs, it uses the docker cache to generate the final image to push. Negating the speed issue anyway, as the actual build must happen once anyway.

[joewragg]

+1 for this

[pgavlin]

We find this useful internally for the same reason as called out above:

we actually find it quite useful to have a verification of the correctness of a dockerfile before applying the update

[AaronFriel]

What behavior would you expect if you passed this flag and any other property was unknown. This would occur if it was an Output that hadn't been resolved at preview time.

Do we:

1. Skip the build despite the flag, silently continue.

2. Fail with an error

3. Try the build with the option ignored

[AaronFriel]

What behavior would you expect if you passed this flag and any other property was unknown. This would occur if it was an Output that hadn't been resolved at preview time.

Do we:

1. Skip the build

2. Fail with an error

3. Try the build without the unknown values (e.g.: missing a build arg, or missing another input to the Image)

[pgavlin]

I’d say skip the build and issue a status log message to notify the user that the build was skipped.

[jamie1911]

Any additional thoughts or current status on this feature? I'd really like to start using some of the newer features of the docker 4.0+ provider.

[stakauskas]

Commenting here as well. Would be great to have it as a switch. Used it to separate build / deploy stages, as in: build images on preview and only reference images on deploy. This way ensuring no time is wasted during deploy on image builds and ensuring that there will be no build failures on deploy.