From 7c9632e4287583aba2158ea8267cecbdefc08f97 Mon Sep 17 00:00:00 2001 From: Bryce Lampe Date: Tue, 16 Apr 2024 13:03:25 -0700 Subject: [PATCH] Regenerate SDKs --- sdk/dotnet/Image.cs | 26 +++++----- sdk/go/dockerbuild/go.mod | 8 +-- sdk/go/dockerbuild/go.sum | 20 +++---- sdk/go/dockerbuild/image.go | 26 +++++----- sdk/go/dockerbuild/x/image.go | 26 +++++----- .../java/com/pulumi/dockerbuild/Image.java | 26 +++++----- sdk/nodejs/image.ts | 30 +++++------ sdk/python/pulumi_docker_build/image.py | 52 +++++++++---------- 8 files changed, 105 insertions(+), 109 deletions(-) diff --git a/sdk/dotnet/Image.cs b/sdk/dotnet/Image.cs index d09b657..f9d19fc 100644 --- a/sdk/dotnet/Image.cs +++ b/sdk/dotnet/Image.cs @@ -28,12 +28,12 @@ namespace Pulumi.DockerBuild /// /// ## Migrating v3 and v4 Image resources /// - /// The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. - /// Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. + /// The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. + /// Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. /// /// ### Behavioral differences /// - /// There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. + /// There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. /// /// #### Previews /// @@ -44,8 +44,8 @@ namespace Pulumi.DockerBuild /// By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. /// Some users felt this made previews in CI less helpful because they no longer detected bad images by default. /// - /// The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. - /// By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. + /// The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. + /// By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. /// Previews run in non-CI environments will not build images. /// This behavior is still configurable with `buildOnPreview`. /// @@ -54,7 +54,7 @@ namespace Pulumi.DockerBuild /// Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. /// They expose a `skipPush: true` option to disable pushing. /// - /// The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. + /// The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. /// /// To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). /// Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -65,7 +65,7 @@ namespace Pulumi.DockerBuild /// /// Version `4.x` of the Pulumi Docker provider does not support secrets. /// - /// The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. + /// The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. /// Instead, they should be passed directly as values. /// (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) /// Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -80,7 +80,7 @@ namespace Pulumi.DockerBuild /// Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. /// This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. /// - /// The `dockerbuild.Image` resource delegates all caching behavior to Docker. + /// The `Image` resource delegates all caching behavior to Docker. /// `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. /// /// #### Outputs @@ -88,7 +88,7 @@ namespace Pulumi.DockerBuild /// Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. /// In `4.x` this could also be a single sha256 hash if the image wasn't pushed. /// - /// Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. + /// Unlike earlier providers the `Image` resource can push multiple tags. /// As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. /// If multiple tags were pushed this uses one at random. /// @@ -101,7 +101,7 @@ namespace Pulumi.DockerBuild /// The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. /// If any are missing a subsequent `update` will push them. /// - /// When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. + /// When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. /// Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). /// Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. /// @@ -109,11 +109,11 @@ namespace Pulumi.DockerBuild /// /// ### Example migration /// - /// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. + /// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. /// /// The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. - /// After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. - /// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. + /// After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. + /// In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. /// /// The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. /// It it is shown with parameters similar to the `v3` example for completeness. diff --git a/sdk/go/dockerbuild/go.mod b/sdk/go/dockerbuild/go.mod index 673fbae..16f8b0e 100644 --- a/sdk/go/dockerbuild/go.mod +++ b/sdk/go/dockerbuild/go.mod @@ -4,7 +4,7 @@ go 1.21.7 require ( github.com/blang/semver v3.5.1+incompatible - github.com/pulumi/pulumi/sdk/v3 v3.111.2-0.20240324200353-583e06df0c70 + github.com/pulumi/pulumi/sdk/v3 v3.113.0 ) require ( @@ -33,7 +33,7 @@ require ( github.com/gogo/protobuf v1.3.2 // indirect github.com/golang/glog v1.2.0 // indirect github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect - github.com/golang/protobuf v1.5.3 // indirect + github.com/golang/protobuf v1.5.4 // indirect github.com/google/uuid v1.6.0 // indirect github.com/grpc-ecosystem/grpc-opentracing v0.0.0-20180507213350-8e809c8a8645 // indirect github.com/hashicorp/errwrap v1.1.0 // indirect @@ -88,8 +88,8 @@ require ( golang.org/x/term v0.18.0 // indirect golang.org/x/text v0.14.0 // indirect golang.org/x/tools v0.19.0 // indirect - google.golang.org/genproto/googleapis/rpc v0.0.0-20240123012728-ef4313101c80 // indirect - google.golang.org/grpc v1.62.0 // indirect + google.golang.org/genproto/googleapis/rpc v0.0.0-20240311173647-c811ad7063a7 // indirect + google.golang.org/grpc v1.62.1 // indirect google.golang.org/protobuf v1.33.0 // indirect gopkg.in/warnings.v0 v0.1.2 // indirect gopkg.in/yaml.v3 v3.0.1 // indirect diff --git a/sdk/go/dockerbuild/go.sum b/sdk/go/dockerbuild/go.sum index f6f66da..1ca4500 100644 --- a/sdk/go/dockerbuild/go.sum +++ b/sdk/go/dockerbuild/go.sum @@ -72,10 +72,8 @@ github.com/golang/glog v1.2.0 h1:uCdmnmatrKCgMBlM4rMuJZWOkPDqdbZPnrMXDY4gI68= github.com/golang/glog v1.2.0/go.mod h1:6AhwSGph0fcJtXVM/PEHPqZlFeoLxhs7/t5UDAwmO+w= github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da h1:oI5xCqsCo564l8iNU+DwB5epxmsaqB+rhGL0m5jtYqE= github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= -github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk= -github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg= -github.com/golang/protobuf v1.5.3/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY= -github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +github.com/golang/protobuf v1.5.4 h1:i7eJL8qZTpSEXOPTxNKhASYpMn+8e5Q6AdndVa1dWek= +github.com/golang/protobuf v1.5.4/go.mod h1:lnTiLA8Wa4RWRcIUkrtSVa5nRhsEGBg48fD6rSs7xps= github.com/google/go-cmp v0.5.9/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= github.com/google/go-cmp v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= github.com/google/go-cmp v0.6.0/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= @@ -156,8 +154,8 @@ github.com/pulumi/appdash v0.0.0-20231130102222-75f619a67231 h1:vkHw5I/plNdTr435 github.com/pulumi/appdash v0.0.0-20231130102222-75f619a67231/go.mod h1:murToZ2N9hNJzewjHBgfFdXhZKjY3z5cYC1VXk+lbFE= github.com/pulumi/esc v0.6.2 h1:+z+l8cuwIauLSwXQS0uoI3rqB+YG4SzsZYtHfNoXBvw= github.com/pulumi/esc v0.6.2/go.mod h1:jNnYNjzsOgVTjCp0LL24NsCk8ZJxq4IoLQdCT0X7l8k= -github.com/pulumi/pulumi/sdk/v3 v3.111.2-0.20240324200353-583e06df0c70 h1:ghmycvyB0Pp1SUgGr49YyLQIaJQhyWicpBDs6mxuqn8= -github.com/pulumi/pulumi/sdk/v3 v3.111.2-0.20240324200353-583e06df0c70/go.mod h1:BZqRjE2GtMYyjB8eNUomPWld+8RaqXKAuYXFqE13JMY= +github.com/pulumi/pulumi/sdk/v3 v3.113.0 h1:CIlmxJZdjxpPPoFe/rrP1dWTwh3CB7ahs/dA6SHcbuE= +github.com/pulumi/pulumi/sdk/v3 v3.113.0/go.mod h1:JWSzKBoHd8rlncC1DhXLf7YdV+Bk/Qf+hSZOOQh0WwQ= github.com/rivo/uniseg v0.1.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc= github.com/rivo/uniseg v0.2.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc= github.com/rivo/uniseg v0.4.4 h1:8TfxU8dW6PdqD27gjM8MVNuicgxIjxpm4K7x4jp8sis= @@ -300,12 +298,10 @@ golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8T golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= -google.golang.org/genproto/googleapis/rpc v0.0.0-20240123012728-ef4313101c80 h1:AjyfHzEPEFp/NpvfN5g+KDla3EMojjhRVZc1i7cj+oM= -google.golang.org/genproto/googleapis/rpc v0.0.0-20240123012728-ef4313101c80/go.mod h1:PAREbraiVEVGVdTZsVWjSbbTtSyGbAgIIvni8a8CD5s= -google.golang.org/grpc v1.62.0 h1:HQKZ/fa1bXkX1oFOvSjmZEUL8wLSaZTjCcLAlmZRtdk= -google.golang.org/grpc v1.62.0/go.mod h1:IWTG0VlJLCh1SkC58F7np9ka9mx/WNkjl4PGJaiq+QE= -google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw= -google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc= +google.golang.org/genproto/googleapis/rpc v0.0.0-20240311173647-c811ad7063a7 h1:8EeVk1VKMD+GD/neyEHGmz7pFblqPjHoi+PGQIlLx2s= +google.golang.org/genproto/googleapis/rpc v0.0.0-20240311173647-c811ad7063a7/go.mod h1:WtryC6hu0hhx87FDGxWCDptyssuo68sk10vYjF+T9fY= +google.golang.org/grpc v1.62.1 h1:B4n+nfKzOICUXMgyrNd19h/I9oH0L1pizfk1d4zSgTk= +google.golang.org/grpc v1.62.1/go.mod h1:IWTG0VlJLCh1SkC58F7np9ka9mx/WNkjl4PGJaiq+QE= google.golang.org/protobuf v1.33.0 h1:uNO2rsAINq/JlFpSdYEKIZ0uKD/R9cpdv0T+yoGwGmI= google.golang.org/protobuf v1.33.0/go.mod h1:c6P6GXX6sHbq/GpV6MGZEdwhWPcYBgnhAHhKbcUYpos= gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= diff --git a/sdk/go/dockerbuild/image.go b/sdk/go/dockerbuild/image.go index 67812be..a81bc11 100644 --- a/sdk/go/dockerbuild/image.go +++ b/sdk/go/dockerbuild/image.go @@ -30,12 +30,12 @@ import ( // // ## Migrating v3 and v4 Image resources // -// The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. -// Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. +// The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. +// Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. // // ### Behavioral differences // -// There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. +// There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. // // #### Previews // @@ -46,8 +46,8 @@ import ( // By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. // Some users felt this made previews in CI less helpful because they no longer detected bad images by default. // -// The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. -// By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. +// The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. +// By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. // Previews run in non-CI environments will not build images. // This behavior is still configurable with `buildOnPreview`. // @@ -56,7 +56,7 @@ import ( // Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. // They expose a `skipPush: true` option to disable pushing. // -// The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. +// The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. // // To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). // Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -67,7 +67,7 @@ import ( // // Version `4.x` of the Pulumi Docker provider does not support secrets. // -// The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. +// The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. // Instead, they should be passed directly as values. // (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) // Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -82,7 +82,7 @@ import ( // Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. // This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. // -// The `dockerbuild.Image` resource delegates all caching behavior to Docker. +// The `Image` resource delegates all caching behavior to Docker. // `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. // // #### Outputs @@ -90,7 +90,7 @@ import ( // Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. // In `4.x` this could also be a single sha256 hash if the image wasn't pushed. // -// Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. +// Unlike earlier providers the `Image` resource can push multiple tags. // As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. // If multiple tags were pushed this uses one at random. // @@ -103,7 +103,7 @@ import ( // The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. // If any are missing a subsequent `update` will push them. // -// When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. +// When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. // Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). // Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. // @@ -111,11 +111,11 @@ import ( // // ### Example migration // -// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. +// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. // // The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. -// After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. -// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. +// After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. +// In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. // // The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. // It it is shown with parameters similar to the `v3` example for completeness. diff --git a/sdk/go/dockerbuild/x/image.go b/sdk/go/dockerbuild/x/image.go index 6e5c5ae..e48b077 100644 --- a/sdk/go/dockerbuild/x/image.go +++ b/sdk/go/dockerbuild/x/image.go @@ -30,12 +30,12 @@ import ( // // ## Migrating v3 and v4 Image resources // -// The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. -// Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. +// The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. +// Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. // // ### Behavioral differences // -// There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. +// There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. // // #### Previews // @@ -46,8 +46,8 @@ import ( // By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. // Some users felt this made previews in CI less helpful because they no longer detected bad images by default. // -// The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. -// By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. +// The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. +// By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. // Previews run in non-CI environments will not build images. // This behavior is still configurable with `buildOnPreview`. // @@ -56,7 +56,7 @@ import ( // Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. // They expose a `skipPush: true` option to disable pushing. // -// The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. +// The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. // // To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). // Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -67,7 +67,7 @@ import ( // // Version `4.x` of the Pulumi Docker provider does not support secrets. // -// The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. +// The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. // Instead, they should be passed directly as values. // (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) // Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -82,7 +82,7 @@ import ( // Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. // This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. // -// The `dockerbuild.Image` resource delegates all caching behavior to Docker. +// The `Image` resource delegates all caching behavior to Docker. // `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. // // #### Outputs @@ -90,7 +90,7 @@ import ( // Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. // In `4.x` this could also be a single sha256 hash if the image wasn't pushed. // -// Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. +// Unlike earlier providers the `Image` resource can push multiple tags. // As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. // If multiple tags were pushed this uses one at random. // @@ -103,7 +103,7 @@ import ( // The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. // If any are missing a subsequent `update` will push them. // -// When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. +// When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. // Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). // Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. // @@ -111,11 +111,11 @@ import ( // // ### Example migration // -// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. +// Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. // // The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. -// After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. -// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. +// After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. +// In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. // // The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. // It it is shown with parameters similar to the `v3` example for completeness. diff --git a/sdk/java/src/main/java/com/pulumi/dockerbuild/Image.java b/sdk/java/src/main/java/com/pulumi/dockerbuild/Image.java index d1e5637..4c2a04a 100644 --- a/sdk/java/src/main/java/com/pulumi/dockerbuild/Image.java +++ b/sdk/java/src/main/java/com/pulumi/dockerbuild/Image.java @@ -44,12 +44,12 @@ import javax.annotation.Nullable; * * ## Migrating v3 and v4 Image resources * - * The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. - * Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. + * The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. + * Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. * * ### Behavioral differences * - * There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. + * There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. * * #### Previews * @@ -60,8 +60,8 @@ import javax.annotation.Nullable; * By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. * Some users felt this made previews in CI less helpful because they no longer detected bad images by default. * - * The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. - * By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. + * The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. + * By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. * Previews run in non-CI environments will not build images. * This behavior is still configurable with `buildOnPreview`. * @@ -70,7 +70,7 @@ import javax.annotation.Nullable; * Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. * They expose a `skipPush: true` option to disable pushing. * - * The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. + * The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. * * To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). * Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -81,7 +81,7 @@ import javax.annotation.Nullable; * * Version `4.x` of the Pulumi Docker provider does not support secrets. * - * The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. + * The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. * Instead, they should be passed directly as values. * (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) * Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -96,7 +96,7 @@ import javax.annotation.Nullable; * Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. * This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. * - * The `dockerbuild.Image` resource delegates all caching behavior to Docker. + * The `Image` resource delegates all caching behavior to Docker. * `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. * * #### Outputs @@ -104,7 +104,7 @@ import javax.annotation.Nullable; * Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. * In `4.x` this could also be a single sha256 hash if the image wasn't pushed. * - * Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. + * Unlike earlier providers the `Image` resource can push multiple tags. * As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. * If multiple tags were pushed this uses one at random. * @@ -117,7 +117,7 @@ import javax.annotation.Nullable; * The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. * If any are missing a subsequent `update` will push them. * - * When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. + * When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. * Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). * Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. * @@ -125,11 +125,11 @@ import javax.annotation.Nullable; * * ### Example migration * - * Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. + * Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. * * The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. - * After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. - * In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. + * After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. + * In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. * * The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. * It it is shown with parameters similar to the `v3` example for completeness. diff --git a/sdk/nodejs/image.ts b/sdk/nodejs/image.ts index af2246a..f3ad8bc 100644 --- a/sdk/nodejs/image.ts +++ b/sdk/nodejs/image.ts @@ -26,12 +26,12 @@ import * as utilities from "./utilities"; * * ## Migrating v3 and v4 Image resources * - * The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. - * Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. + * The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. + * Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. * * ### Behavioral differences * - * There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. + * There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. * * #### Previews * @@ -42,8 +42,8 @@ import * as utilities from "./utilities"; * By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. * Some users felt this made previews in CI less helpful because they no longer detected bad images by default. * - * The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. - * By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. + * The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. + * By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. * Previews run in non-CI environments will not build images. * This behavior is still configurable with `buildOnPreview`. * @@ -52,7 +52,7 @@ import * as utilities from "./utilities"; * Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. * They expose a `skipPush: true` option to disable pushing. * - * The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. + * The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. * * To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). * Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -63,7 +63,7 @@ import * as utilities from "./utilities"; * * Version `4.x` of the Pulumi Docker provider does not support secrets. * - * The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. + * The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. * Instead, they should be passed directly as values. * (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) * Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -78,7 +78,7 @@ import * as utilities from "./utilities"; * Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. * This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. * - * The `dockerbuild.Image` resource delegates all caching behavior to Docker. + * The `Image` resource delegates all caching behavior to Docker. * `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. * * #### Outputs @@ -86,7 +86,7 @@ import * as utilities from "./utilities"; * Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. * In `4.x` this could also be a single sha256 hash if the image wasn't pushed. * - * Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. + * Unlike earlier providers the `Image` resource can push multiple tags. * As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. * If multiple tags were pushed this uses one at random. * @@ -99,7 +99,7 @@ import * as utilities from "./utilities"; * The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. * If any are missing a subsequent `update` will push them. * - * When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. + * When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. * Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). * Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. * @@ -107,11 +107,11 @@ import * as utilities from "./utilities"; * * ### Example migration * - * Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. + * Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. * * The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. - * After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. - * In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. + * After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. + * In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. * * The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. * It it is shown with parameters similar to the `v3` example for completeness. @@ -160,7 +160,7 @@ import * as utilities from "./utilities"; * }, * }); * - * // v3 Image after migrating to dockerbuild.Image + * // v3 Image after migrating to docker-build.Image * const v3Migrated = new dockerbuild.Image("v3-to-buildx", { * tags: ["myregistry.com/user/repo:latest", "local-tag"], * push: true, @@ -219,7 +219,7 @@ import * as utilities from "./utilities"; * }, * }); * - * // v4 Image after migrating to dockerbuild.Image + * // v4 Image after migrating to docker-build.Image * const v4Migrated = new dockerbuild.Image("v4-to-buildx", { * tags: ["myregistry.com/user/repo:latest"], * push: true, diff --git a/sdk/python/pulumi_docker_build/image.py b/sdk/python/pulumi_docker_build/image.py index f82d1b5..ffea363 100644 --- a/sdk/python/pulumi_docker_build/image.py +++ b/sdk/python/pulumi_docker_build/image.py @@ -629,12 +629,12 @@ class Image(pulumi.CustomResource): ## Migrating v3 and v4 Image resources - The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. - Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. + The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. + Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. ### Behavioral differences - There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. + There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. #### Previews @@ -645,8 +645,8 @@ class Image(pulumi.CustomResource): By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. Some users felt this made previews in CI less helpful because they no longer detected bad images by default. - The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. - By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. + The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. + By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. Previews run in non-CI environments will not build images. This behavior is still configurable with `buildOnPreview`. @@ -655,7 +655,7 @@ class Image(pulumi.CustomResource): Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. They expose a `skipPush: true` option to disable pushing. - The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. + The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -666,7 +666,7 @@ class Image(pulumi.CustomResource): Version `4.x` of the Pulumi Docker provider does not support secrets. - The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. + The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. Instead, they should be passed directly as values. (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -681,7 +681,7 @@ class Image(pulumi.CustomResource): Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. - The `dockerbuild.Image` resource delegates all caching behavior to Docker. + The `Image` resource delegates all caching behavior to Docker. `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. #### Outputs @@ -689,7 +689,7 @@ class Image(pulumi.CustomResource): Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. In `4.x` this could also be a single sha256 hash if the image wasn't pushed. - Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. + Unlike earlier providers the `Image` resource can push multiple tags. As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. If multiple tags were pushed this uses one at random. @@ -702,7 +702,7 @@ class Image(pulumi.CustomResource): The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. If any are missing a subsequent `update` will push them. - When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. + When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. @@ -710,11 +710,11 @@ class Image(pulumi.CustomResource): ### Example migration - Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. + Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. - After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. - In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. + After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. + In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. It it is shown with parameters similar to the `v3` example for completeness. @@ -1066,12 +1066,12 @@ class Image(pulumi.CustomResource): ## Migrating v3 and v4 Image resources - The `dockerbuild.Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. - Existing `Image` resources can be converted to `dockerbuild.Image` resources with minor modifications. + The `Image` resource provides a superset of functionality over the `Image` resources available in versions 3 and 4 of the Pulumi Docker provider. + Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications. ### Behavioral differences - There are several key behavioral differences to keep in mind when transitioning images to the new `dockerbuild.Image` resource. + There are several key behavioral differences to keep in mind when transitioning images to the new `Image` resource. #### Previews @@ -1082,8 +1082,8 @@ class Image(pulumi.CustomResource): By default, `v4.x` `Image` resources do _not_ build during previews, but this behavior can be toggled with the `buildOnPreview` option. Some users felt this made previews in CI less helpful because they no longer detected bad images by default. - The default behavior of the `dockerbuild.Image` resource has been changed to strike a better balance between CI use cases and manual updates. - By default, Pulumi will now only build `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. + The default behavior of the `Image` resource has been changed to strike a better balance between CI use cases and manual updates. + By default, Pulumi will now only build `Image` resources during previews when it detects a CI environment like GitHub Actions. Previews run in non-CI environments will not build images. This behavior is still configurable with `buildOnPreview`. @@ -1092,7 +1092,7 @@ class Image(pulumi.CustomResource): Versions `3.x` and `4.x` of the Pulumi Docker provider attempt to push images to remote registries by default. They expose a `skipPush: true` option to disable pushing. - The `dockerbuild.Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. + The `Image` resource matches the Docker CLI's behavior and does not push images anywhere by default. To push images to a registry you can include `push: true` (equivalent to Docker's `--push` flag) or configure an `export` of type `registry` (equivalent to Docker's `--output type=registry`). Like Docker, if an image is configured without exports you will see a warning with instructions for how to enable pushing, but the build will still proceed normally. @@ -1103,7 +1103,7 @@ class Image(pulumi.CustomResource): Version `4.x` of the Pulumi Docker provider does not support secrets. - The `dockerbuild.Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. + The `Image` resource supports secrets but does not require those secrets to exist on-disk or in environment variables. Instead, they should be passed directly as values. (Please be sure to familiarize yourself with Pulumi's [native secret handling](https://www.pulumi.com/docs/concepts/secrets/).) Pulumi also provides [ESC](https://www.pulumi.com/product/esc/) to make it easier to share secrets across stacks and environments. @@ -1118,7 +1118,7 @@ class Image(pulumi.CustomResource): Both versions 3 and 4 require specific environment variables to be set and deviate from Docker's native caching behavior. This can result in inefficient builds due to unnecessary image pulls, repeated file transfers, etc. - The `dockerbuild.Image` resource delegates all caching behavior to Docker. + The `Image` resource delegates all caching behavior to Docker. `cacheFrom` and `cacheTo` options (equivalent to Docker's `--cache-to` and `--cache-from`) are exposed and provide additional cache targets, such as local disk, S3 storage, etc. #### Outputs @@ -1126,7 +1126,7 @@ class Image(pulumi.CustomResource): Versions `3.x` and `4.x` of the provider exposed a `repoDigest` output which was a fully qualified tag with digest. In `4.x` this could also be a single sha256 hash if the image wasn't pushed. - Unlike earlier providers the `dockerbuild.Image` resource can push multiple tags. + Unlike earlier providers the `Image` resource can push multiple tags. As a convenience, it exposes a `ref` output consisting of a tag with digest as long as the image was pushed. If multiple tags were pushed this uses one at random. @@ -1139,7 +1139,7 @@ class Image(pulumi.CustomResource): The `buidx.Image` will query your registries during `refresh` to ensure the expected tags exist. If any are missing a subsequent `update` will push them. - When a `dockerbuild.Image` is deleted, it will _attempt_ to also delete any pushed tags. + When a `Image` is deleted, it will _attempt_ to also delete any pushed tags. Deletion of remote tags is not guaranteed because not all registries support the manifest `DELETE` API (`docker.io` in particular). Manifests are _not_ deleted in the same way during updates -- to do so safely would require a full build to determine whether a Pulumi operation should be an update or update-replace. @@ -1147,11 +1147,11 @@ class Image(pulumi.CustomResource): ### Example migration - Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `dockerbuild.Image` resource showing how they would look after migration. + Examples of "fully-featured" `v3` and `v4` `Image` resources are shown below, along with an example `Image` resource showing how they would look after migration. The `v3` resource leverages `buildx` via a `DOCKER_BUILDKIT` environment variable and CLI flags passed in with `extraOption`. - After migration, the environment variable is no longer needed and CLI flags are now properties on the `dockerbuild.Image`. - In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. + After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`. + In almost all cases, properties of `Image` are named after the Docker CLI flag they correspond to. The `v4` resource is less functional than its `v3` counterpart because it lacks the flexibility of `extraOptions`. It it is shown with parameters similar to the `v3` example for completeness.