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
///
/// 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.

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

@@ -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

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/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=

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

@@ -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.

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

@@ -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.

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
*
* 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.

30
sdk/nodejs/image.ts generated
View File

@@ -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,

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
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.