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

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.