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

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,