sam_oneal/pulumi-docker-build
1
0
Fork 0
Code Actions Packages Releases Wiki Activity

Regenerate SDKs

Browse Source
This commit is contained in:
Bryce Lampe
2024-04-16 13:03:25 -07:00
parent eca03ce6db
commit 7c9632e428
8 changed files with 105 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
sdk/dotnet/Image.cs generated
View File

@@ -28,12 +28,12 @@ namespace Pulumi.DockerBuild
/// ///
/// ## Migrating v3 and v4 Image resources /// ## 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. /// 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 `dockerbuild.Image` resources with minor modifications. /// Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
/// ///
/// ### Behavioral differences /// ### 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 /// #### 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. /// 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. /// 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. /// 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. /// 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. /// Previews run in non-CI environments will not build images.
/// This behavior is still configurable with `buildOnPreview`. /// 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. /// 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. /// 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`). /// 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. /// 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. /// 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. /// 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/).) /// (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. /// 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. /// 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. /// 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. /// `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 /// #### 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. /// 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. /// 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. /// 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. /// 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. /// 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. /// 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). /// 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. /// 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 /// ### 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`. /// 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`. /// After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
/// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. /// 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`. /// 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. /// It it is shown with parameters similar to the `v3` example for completeness.

8
sdk/go/dockerbuild/go.mod generated
View File

@@ -4,7 +4,7 @@ go 1.21.7
require ( require (
github.com/blang/semver v3.5.1+incompatible 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 ( require (
@@ -33,7 +33,7 @@ require (
github.com/gogo/protobuf v1.3.2 // indirect github.com/gogo/protobuf v1.3.2 // indirect
github.com/golang/glog v1.2.0 // indirect github.com/golang/glog v1.2.0 // indirect
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // 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/google/uuid v1.6.0 // indirect
github.com/grpc-ecosystem/grpc-opentracing v0.0.0-20180507213350-8e809c8a8645 // indirect github.com/grpc-ecosystem/grpc-opentracing v0.0.0-20180507213350-8e809c8a8645 // indirect
github.com/hashicorp/errwrap v1.1.0 // 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/term v0.18.0 // indirect
golang.org/x/text v0.14.0 // indirect golang.org/x/text v0.14.0 // indirect
golang.org/x/tools v0.19.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/genproto/googleapis/rpc v0.0.0-20240311173647-c811ad7063a7 // indirect
google.golang.org/grpc v1.62.0 // indirect google.golang.org/grpc v1.62.1 // indirect
google.golang.org/protobuf v1.33.0 // indirect google.golang.org/protobuf v1.33.0 // indirect
gopkg.in/warnings.v0 v0.1.2 // indirect gopkg.in/warnings.v0 v0.1.2 // indirect
gopkg.in/yaml.v3 v3.0.1 // indirect gopkg.in/yaml.v3 v3.0.1 // indirect

20
sdk/go/dockerbuild/go.sum generated
View File

@@ -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/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 h1:oI5xCqsCo564l8iNU+DwB5epxmsaqB+rhGL0m5jtYqE=
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= 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.4 h1:i7eJL8qZTpSEXOPTxNKhASYpMn+8e5Q6AdndVa1dWek=
github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg= github.com/golang/protobuf v1.5.4/go.mod h1:lnTiLA8Wa4RWRcIUkrtSVa5nRhsEGBg48fD6rSs7xps=
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/google/go-cmp v0.5.9/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= 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 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
github.com/google/go-cmp v0.6.0/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= 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/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 h1:+z+l8cuwIauLSwXQS0uoI3rqB+YG4SzsZYtHfNoXBvw=
github.com/pulumi/esc v0.6.2/go.mod h1:jNnYNjzsOgVTjCp0LL24NsCk8ZJxq4IoLQdCT0X7l8k= 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.113.0 h1:CIlmxJZdjxpPPoFe/rrP1dWTwh3CB7ahs/dA6SHcbuE=
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/go.mod h1:JWSzKBoHd8rlncC1DhXLf7YdV+Bk/Qf+hSZOOQh0WwQ=
github.com/rivo/uniseg v0.1.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc= 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.2.0/go.mod h1:J6wj4VEh+S6ZtnVlnTBMWIodfgj8LQOQFoIToxlJtxc=
github.com/rivo/uniseg v0.4.4 h1:8TfxU8dW6PdqD27gjM8MVNuicgxIjxpm4K7x4jp8sis= 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-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-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/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-20240311173647-c811ad7063a7 h1:8EeVk1VKMD+GD/neyEHGmz7pFblqPjHoi+PGQIlLx2s=
google.golang.org/genproto/googleapis/rpc v0.0.0-20240123012728-ef4313101c80/go.mod h1:PAREbraiVEVGVdTZsVWjSbbTtSyGbAgIIvni8a8CD5s= google.golang.org/genproto/googleapis/rpc v0.0.0-20240311173647-c811ad7063a7/go.mod h1:WtryC6hu0hhx87FDGxWCDptyssuo68sk10vYjF+T9fY=
google.golang.org/grpc v1.62.0 h1:HQKZ/fa1bXkX1oFOvSjmZEUL8wLSaZTjCcLAlmZRtdk= google.golang.org/grpc v1.62.1 h1:B4n+nfKzOICUXMgyrNd19h/I9oH0L1pizfk1d4zSgTk=
google.golang.org/grpc v1.62.0/go.mod h1:IWTG0VlJLCh1SkC58F7np9ka9mx/WNkjl4PGJaiq+QE= google.golang.org/grpc v1.62.1/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/protobuf v1.33.0 h1:uNO2rsAINq/JlFpSdYEKIZ0uKD/R9cpdv0T+yoGwGmI= google.golang.org/protobuf v1.33.0 h1:uNO2rsAINq/JlFpSdYEKIZ0uKD/R9cpdv0T+yoGwGmI=
google.golang.org/protobuf v1.33.0/go.mod h1:c6P6GXX6sHbq/GpV6MGZEdwhWPcYBgnhAHhKbcUYpos= 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= gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=

26
sdk/go/dockerbuild/image.go generated
View File

@@ -30,12 +30,12 @@ import (
// //
// ## Migrating v3 and v4 Image resources // ## 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. // 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 `dockerbuild.Image` resources with minor modifications. // Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
// //
// ### Behavioral differences // ### 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 // #### 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. // 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. // 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. // 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. // 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. // Previews run in non-CI environments will not build images.
// This behavior is still configurable with `buildOnPreview`. // 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. // 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. // 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`). // 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. // 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. // 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. // 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/).) // (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. // 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. // 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. // 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. // `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 // #### 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. // 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. // 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. // 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. // 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. // 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. // 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). // 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. // 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 // ### 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`. // 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`. // After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. // 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`. // 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. // It it is shown with parameters similar to the `v3` example for completeness.

26
sdk/go/dockerbuild/x/image.go generated
View File

@@ -30,12 +30,12 @@ import (
// //
// ## Migrating v3 and v4 Image resources // ## 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. // 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 `dockerbuild.Image` resources with minor modifications. // Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
// //
// ### Behavioral differences // ### 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 // #### 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. // 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. // 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. // 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. // 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. // Previews run in non-CI environments will not build images.
// This behavior is still configurable with `buildOnPreview`. // 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. // 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. // 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`). // 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. // 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. // 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. // 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/).) // (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. // 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. // 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. // 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. // `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 // #### 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. // 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. // 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. // 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. // 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. // 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. // 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). // 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. // 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 // ### 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`. // 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`. // After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
// In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. // 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`. // 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. // It it is shown with parameters similar to the `v3` example for completeness.

26
sdk/java/src/main/java/com/pulumi/dockerbuild/Image.java generated
View File

@@ -44,12 +44,12 @@ import javax.annotation.Nullable;
* *
* ## Migrating v3 and v4 Image resources * ## 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. * 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 `dockerbuild.Image` resources with minor modifications. * Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
* *
* ### Behavioral differences * ### 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 * #### 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. * 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. * 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. * 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. * 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. * Previews run in non-CI environments will not build images.
* This behavior is still configurable with `buildOnPreview`. * 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. * 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. * 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`). * 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. * 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. * 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. * 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/).) * (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. * 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. * 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. * 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. * `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 * #### 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. * 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. * 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. * 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. * 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. * 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. * 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). * 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. * 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 * ### 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`. * 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`. * After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
* In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. * 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`. * 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. * It it is shown with parameters similar to the `v3` example for completeness.

30
sdk/nodejs/image.ts generated
View File

@@ -26,12 +26,12 @@ import * as utilities from "./utilities";
* *
* ## Migrating v3 and v4 Image resources * ## 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. * 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 `dockerbuild.Image` resources with minor modifications. * Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
* *
* ### Behavioral differences * ### 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 * #### 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. * 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. * 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. * 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. * 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. * Previews run in non-CI environments will not build images.
* This behavior is still configurable with `buildOnPreview`. * 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. * 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. * 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`). * 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. * 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. * 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. * 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/).) * (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. * 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. * 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. * 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. * `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 * #### 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. * 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. * 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. * 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. * 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. * 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. * 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). * 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. * 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 * ### 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`. * 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`. * After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
* In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. * 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`. * 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. * 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", { * const v3Migrated = new dockerbuild.Image("v3-to-buildx", {
* tags: ["myregistry.com/user/repo:latest", "local-tag"], * tags: ["myregistry.com/user/repo:latest", "local-tag"],
* push: true, * 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", { * const v4Migrated = new dockerbuild.Image("v4-to-buildx", {
* tags: ["myregistry.com/user/repo:latest"], * tags: ["myregistry.com/user/repo:latest"],
* push: true, * push: true,

52
sdk/python/pulumi_docker_build/image.py generated
View File

@@ -629,12 +629,12 @@ class Image(pulumi.CustomResource):
## Migrating v3 and v4 Image resources ## 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. 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 `dockerbuild.Image` resources with minor modifications. Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
### Behavioral differences ### 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 #### 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. 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. 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. 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. 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. Previews run in non-CI environments will not build images.
This behavior is still configurable with `buildOnPreview`. 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. 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. 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`). 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. 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. 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. 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/).) (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. 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. 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. 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. `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 #### 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. 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. 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. 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. 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. 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. 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). 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. 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 ### 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`. 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`. After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. 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`. 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. 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 ## 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. 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 `dockerbuild.Image` resources with minor modifications. Existing `Image` resources can be converted to the docker-build `Image` resources with minor modifications.
### Behavioral differences ### 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 #### 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. 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. 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. 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 `dockerbuild.Image` resources during previews when it detects a CI environment like GitHub Actions. 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. Previews run in non-CI environments will not build images.
This behavior is still configurable with `buildOnPreview`. 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. 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. 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`). 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. 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. 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. 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/).) (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. 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. 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. 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. `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 #### 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. 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. 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. 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. 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. 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. 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). 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. 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 ### 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`. 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`. After migration, the environment variable is no longer needed and CLI flags are now properties on the `Image`.
In almost all cases, properties of `dockerbuild.Image` are named after the Docker CLI flag they correspond to. 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`. 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. It it is shown with parameters similar to the `v3` example for completeness.