Use fully qualified image names

content/docs/app-journey.md

@@ -63,7 +63,7 @@ cd samples/apps/java-maven
 
 3. Build the app using [`pack`][pack-docs]
 ```
-pack build myapp --builder cnbs/sample-builder:jammy
+pack build myapp --builder docker.io/cnbs/sample-builder:jammy
 ```
 <!--+- "{{execute}}"+-->
 

content/docs/for-app-developers/concepts/base-images/stack.md

@@ -42,8 +42,8 @@ Stacks are used by [builders][builder] and are configured through a builder's
 
 [stack]
   id = "com.example.stack"
-  build-image = "example/build"
-  run-image = "example/run"
+  build-image = "docker.io/example/build"
+  run-image = "docker.io/example/run"
   run-image-mirrors = ["gcr.io/example/run", "registry.example.com/example/run"]
 ```
 

content/docs/for-app-developers/concepts/rebase.md

@@ -24,12 +24,13 @@ If so, `rebase` updates the app image's layer metadata to reference the newer ba
 
 ### Example: Rebasing an app image
 
-Consider an app image `my-app:my-tag` that was originally built using the default builder.
-That builder has a reference to a run image called `pack/run`.
-Running the following will update the base of `my-app:my-tag` with the latest version of `pack/run`.
+Consider an app image `registry.example.com/example/my-app:my-tag` that was originally built using the default builder.
+That builder has a reference to a run image called `registry.example.com/example/run`.
+Running the following will update the base of `registry.example.com/example/my-app:my-tag` with the latest version of
+`registry.example.com/example/run`.
 
 ```bash
-$ pack rebase my-app:my-tag
+$ pack rebase registry.example.com/example/my-app:my-tag
 ```
 
 > **TIP:** `pack rebase` has a `--publish` flag that can be used to publish the updated app image directly to a registry. 

content/docs/for-app-developers/concepts/reproducibility.md

@@ -30,7 +30,7 @@ Running `pack build sample-hello-moon:test` multiple times produces a container
 - The same set of buildpacks (see caveat below).
 
 ---
-Running `pack build cnbs/sample-hello-world:test --publish` multiple times produces a container image with the same image digest (*remote* case)
+Running `pack build registry.example.com/example/sample-hello-world:test --publish` multiple times produces a container image with the same image digest (*remote* case)
 
 **Given**:
 - The same source code
@@ -40,21 +40,30 @@ Running `pack build cnbs/sample-hello-world:test --publish` multiple times produ
 Inspecting the results of the above command, we see the following output:
 
 ```bash
-$ docker pull cnbs/sample-hello-world:test && docker images --digest # Pull remotely created image and view IDs and Digests
-REPOSITORY                                   TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
-sample-hello-world                           test                sha256:9e3cfea3f90fb4fbbe855a2cc9ce505087ae10d6805cfcb44bd67a4b72628641   597c49cae461        40 years ago        95.2MB
-sample-hello-moon-app                        test                <none>                                                                    86aab15e22b8        40 years ago        43MB
+$ docker pull registry.example.com/example/sample-hello-world:test && docker images --digests # Pull remotely created image and view IDs and Digests
+REPOSITORY                                        TAG    DIGEST                                                                    IMAGE ID       CREATED         SIZE
+registry.example.com/example/sample-hello-world   test   sha256:9e3cfea3f90fb4fbbe855a2cc9ce505087ae10d6805cfcb44bd67a4b72628641   597c49cae461   40 years ago    95.2MB
+sample-hello-moon                                 test   <none>                                                                    86aab15e22b8   40 years ago    43MB
 ```
 
 ### Consequences and Caveats
 
-There are a couple things to note about the above output:
+There are a couple of things to note about the above output:
 - We achieve reproducible builds by "zeroing" various timestamps of the layers of the output image. When images are inspected they may have confusing creation times (eg. "40 years ago").
-- The `cnbs/sample-hello-moon:test` image does not have an entry for the "DIGEST" column. This is because the digest is produced from the image's manifest and a manifest is only created when an image is stored in a remote registry.
+- The `sample-hello-moon:test` image does not have an entry for the "DIGEST" column. This is because the digest is produced from the image's manifest and a manifest is only created when an image is stored in a remote registry.
 
 The CNB lifecycle cannot fix non-reproducible buildpack layer file contents. This means that the underlying buildpack and language ecosystem have to implement reproducible output (for example `go` binaries are reproducible by default). Buildpacks that produce identical layers given the same input could be said to be reproducible buildpacks.
 
-Running `pack build cnbs/test-image:test && docker push cnbs/test-image:test` and `pack build cnbs/test-image:test --publish` with the same inputs will not produce the same image digest because:
+Even with the same inputs, running two commands below will not produce the same image digest.
+
+```bash
+# pack build and docker push
+$ pack build registry.example.com/example/test-image:test && docker push registry.example.com/example/test-image:test
+
+# pack build with "--publish" flag
+$ pack build registry.example.com/example/test-image:test --publish
+```
+
+This is because: 
 - The remote image will have an image digest reference in the `runImage.reference` field in the `io.buildpacks.lifecycle.metadata` label
 - The local image will have an image ID in the `runImage.reference` field in the `io.buildpacks.lifecycle.metadata` label if it was created locally
-

content/docs/for-app-developers/how-to/build-inputs/configure-build-time-environment.md

@@ -33,10 +33,10 @@ export FOO=BAR
 pack build sample-app \
     --env "HELLO=WORLD" \
     --env "FOO" \
-    --builder cnbs/sample-builder:jammy \
-    --buildpack  samples/buildpacks/hello-world/ \
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --buildpack samples/buildpacks/hello-world/ \
     --buildpack samples/apps/bash-script/bash-script-buildpack/ \
-    --path  samples/apps/bash-script/
+    --path samples/apps/bash-script/
 ```
 <!--+- "{{execute}}"+-->
 
@@ -79,10 +79,10 @@ echo -en "HELLO=WORLD\nFOO" > ./envfile
 ```
 pack build sample-app \
     --env-file ./envfile \
-    --builder cnbs/sample-builder:jammy \
-    --buildpack  samples/buildpacks/hello-world/ \
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --buildpack samples/buildpacks/hello-world/ \
     --buildpack samples/apps/bash-script/bash-script-buildpack/ \
-    --path  samples/apps/bash-script/
+    --path samples/apps/bash-script/
 ```
 <!--+- "{{execute}}"+-->
 
@@ -125,10 +125,10 @@ EOL
 2. Build the app
 ```
 pack build sample-app \
-    --builder cnbs/sample-builder:jammy \
-    --buildpack  samples/buildpacks/hello-world/ \
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --buildpack samples/buildpacks/hello-world/ \
     --buildpack samples/apps/bash-script/bash-script-buildpack/ \
-    --path  samples/apps/bash-script/
+    --path samples/apps/bash-script/
 ```
 <!--+- "{{execute}}"+-->
 

content/docs/for-app-developers/how-to/build-inputs/specify-buildpacks.md

@@ -39,10 +39,10 @@ For this example we will use a few buildpacks from our [samples][samples] repo.
 
 ```
 pack build sample-java-maven-app \
-    --builder cnbs/sample-builder:alpine \
+    --builder registry.example.com/example/builder:alpine \
     --buildpack samples/java-maven \
     --buildpack samples/buildpacks/hello-processes/ \
-    --buildpack docker://cnbs/sample-package:hello-universe \
+    --buildpack docker://registry.example.com/example/sample-package:hello-universe \
     --path samples/apps/java-maven/
 ```
 <!--+- "{{execute}}"+-->
@@ -78,7 +78,7 @@ uri = "samples/java-maven"
 uri = "samples/buildpacks/hello-processes/"
 
 [[io.buildpacks.group]]
-uri = "docker://cnbs/sample-package:hello-universe"
+uri = "docker://registry.example.com/example/sample-package:hello-universe"
 ```
 
 ## URI Examples

content/docs/for-app-developers/how-to/build-inputs/use-cache-image.md

@@ -32,7 +32,7 @@ For the following examples we will use:
 Next we trust the `cnbs/sample-builder:jammy` builder in order to allow access to docker credentials when publishing.
 
 ```
-pack config trusted-builders add cnbs/sample-builder:jammy
+pack config trusted-builders add docker.io/cnbs/sample-builder:jammy
 ```
 <!--+- "{{execute}}"+-->
 
@@ -42,7 +42,7 @@ To build the `localhost:5000/buildpack-examples/cache-image-example` application
 
 ```
 pack build localhost:5000/buildpack-examples/cache-image-example \
-    --builder cnbs/sample-builder:jammy \
+    --builder docker.io/cnbs/sample-builder:jammy \
     --buildpack samples/java-maven \
     --path samples/apps/java-maven \
     --cache-image localhost:5000/buildpack-examples/maven-cache-image:latest \
@@ -76,7 +76,7 @@ builds may also update the specified `cache-image`.
 The following command will restore data for the `samples/java-maven:maven_m2` layer from the cache image.
 ```
 pack build localhost:5000/buildpack-examples/second-cache-image-example \
-    --builder cnbs/sample-builder:jammy \
+    --builder docker.io/cnbs/sample-builder:jammy \
     --buildpack samples/java-maven \
     --path samples/apps/java-maven \
     --cache-image localhost:5000/buildpack-examples/maven-cache-image:latest \

content/docs/for-app-developers/how-to/build-inputs/use-project-toml.md

@@ -45,8 +45,8 @@ To use a `project.toml` file, simply:
 ```shell script
 # build the app
 pack build sample-app \
-    --builder cnbs/sample-builder:jammy \
-    --path  samples/apps/bash-script/
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --path samples/apps/bash-script/
 
 # run the app
 docker run sample-app
@@ -55,9 +55,9 @@ docker run sample-app
 If the descriptor is named `project.toml`, it will be read by `pack` automatically. Otherwise, you can run:
 ```shell script
 pack build sample-app \
-    --builder cnbs/sample-builder:jammy \
-    --path  samples/apps/bash-script/ \
-    --descriptor  samples/apps/bash-script/<project-descriptor-file.toml>
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --path samples/apps/bash-script/ \
+    --descriptor samples/apps/bash-script/<project-descriptor-file.toml>
 ```
 to specify an alternatively named `project descriptor`.
 
@@ -99,8 +99,8 @@ Paste the above `toml` as `new-project.toml` in the `samples/apps/bash-script/`
 ```shell script
 # build the app
 pack build sample-app \
-    --builder cnbs/sample-builder:jammy \
-    --path  samples/apps/bash-script/ \
+    --builder docker.io/cnbs/sample-builder:jammy \
+    --path samples/apps/bash-script/ \
     --descriptor samples/apps/bash-script/new-project.toml
 
 # run the app

content/docs/for-app-developers/how-to/build-inputs/use-volume-mounts.md

@@ -83,7 +83,7 @@ Now, we can mount this volume during `pack build`:
 ```bash
 ls -al
 pack build volume-example \
-    --builder cnbs/sample-builder:jammy \
+    --builder docker.io/cnbs/sample-builder:jammy \
     --buildpack samples/buildpacks/hello-world \
     --path samples/apps/bash-script \
     --volume test-volume:/platform/volume:ro

content/docs/for-app-developers/how-to/build-outputs/download-sbom.md

@@ -19,13 +19,13 @@ A **Software-Bill-of-Materials** (`SBOM`) lists all the software components incl
 You can use the `sbom download` command to inspect your app for its Software-Bill-of-Materials. The following command will download the application layer containing the `SBOM` files to `./layers/sbom/...` on your local filesystem.
 
 ```bash
-pack sbom download your-image-name
+pack sbom download my-app:my-tag
 ```
 
 You can also choose to download the `SBOM` from an image hosted in a remote registry, as opposed to an image hosted in a Docker daemon. You use the `--remote` flag to do so.
 
 ```bash
-pack sbom download your-image-name --remote
+pack sbom download registry.example.com/example/my-app:my-tag --remote
 ```
 
 The following example demonstrates  running `pack sbom download ...` on an image containing an `SBOM` in  `syft` format.  Running `pack sbom download ...` creates a `layers/sbom` directory and populates that directory with `sbom.syft.json` files.  The combined metadata from all of the `sbom.syft.json` files is the image `SBOM`. Where an image generates CycloneDX `SBOM` metadata, the files are named `sbom.cdx.json`. Similarly, Spdx files are named `sbom.spdx.json`.

content/docs/for-app-developers/how-to/build-outputs/specify-launch-process.md

@@ -17,7 +17,7 @@ For this example we will use the `hello-processes` buildpack from our [samples][
 Let's build the app.
 ```
 pack build multi-process-app \
-    --builder cnbs/sample-builder:alpine \
+    --builder docker.io/cnbs/sample-builder:alpine \
     --buildpack samples/java-maven \
     --buildpack samples/buildpacks/hello-processes/ \
     --path samples/apps/java-maven/

content/docs/for-app-developers/how-to/special-cases/build-for-arm.md

@@ -81,8 +81,8 @@ docker run --rm \
   --volume ~/workspace/platform:/platform \
   --mount type=bind,source=~/workspace/order.toml,target=/cnb/order.toml \
   --env CNB_PLATFORM_API=0.7 \
-  ubuntu:jammy \
-  /cnb/lifecycle/creator -log-level debug -daemon -run-image ubuntu:jammy hello-arm64
+  docker.io/ubuntu:jammy \
+  /cnb/lifecycle/creator -log-level debug -daemon -run-image docker.io/ubuntu:jammy hello-arm64
 ```
 
 ### 4. Run it

content/docs/for-app-developers/how-to/special-cases/build-for-windows.md

@@ -65,7 +65,7 @@ To [build][build] an app you must first decide which [builder][builder] you're g
 includes the [buildpacks][buildpack] that will be used as well as the environment for building your
 app.
 
-For this guide we're going to use a sample builder, `cnbs/sample-builder:dotnet-framework-1809`.
+For this guide we're going to use a sample builder, `docker.io/cnbs/sample-builder:dotnet-framework-1809`.
 
 ### 2. Build your app
 
@@ -79,7 +79,7 @@ git clone https://github.com/buildpacks/samples
 cd samples
 
 # build the app
-pack build sample-app --path apps/aspnet --builder cnbs/sample-builder:dotnet-framework-1809 --trust-builder
+pack build sample-app --path apps/aspnet --builder docker.io/cnbs/sample-builder:dotnet-framework-1809 --trust-builder
 ```
 
 > **TIP:** The builder may take a few minutes to download on the first use.
@@ -116,7 +116,7 @@ ssh -f -N -L 2375:127.0.0.1:2375 10.0.0.1
 export DOCKER_HOST=tcp://localhost:2375
 
 # build the app
-pack build sample-app --path samples/apps/aspnet --builder cnbs/sample-builder:dotnet-framework-1809 --trust-builder
+pack build sample-app --path samples/apps/aspnet --builder docker.io/cnbs/sample-builder:dotnet-framework-1809 --trust-builder
 
 # run it
 docker run --rm -it -p 8080:80 sample-app

content/docs/for-app-developers/how-to/special-cases/build-on-podman.md

@@ -49,7 +49,7 @@ git clone https://github.com/buildpacks/samples
 ![](https://i.imgur.com/0mmV6K7.png)
 
 ```shell=bash
-pack build sample-app -p samples/apps/ruby-bundler/ -B cnbs/sample-builder:jammy
+pack build sample-app -p samples/apps/ruby-bundler/ -B docker.io/cnbs/sample-builder:jammy
 ```
 
 Where:

content/docs/for-app-developers/how-to/special-cases/export-to-oci-layout.md

@@ -51,7 +51,7 @@ The OCI layout feature must be enabled using the convention `oci:<path/to/save/i
 For example:
 
 ```bash
-pack build oci:sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic
+pack build oci:sample-app --path samples/apps/java-maven --builder docker.io/cnbs/sample-builder:bionic
 ```
 
 It will save the image in a folder `./sample-app` created in your current directory.
@@ -101,7 +101,7 @@ If you don't need your `run-image` layers on disk, you can skip them using `--sp
 For example:
 
 ```bash
-pack build oci:sample-app --sparse --path samples/apps/java-maven --builder cnbs/sample-builder:bionic
+pack build oci:sample-app --sparse --path samples/apps/java-maven --builder docker.io/cnbs/sample-builder:bionic
 ```
 
 Verify your application image
@@ -151,8 +151,3 @@ But [crane](https://github.com/google/go-containerregistry/tree/main/cmd/crane)
 crane pull <your-image> <dest> --format=oci
 ```
 It will give you `application/vnd.docker.distribution.manifest.list.v2+json`, which will fail because of the [state of our current implementation](https://github.com/buildpacks/rfcs/pull/203#discussion_r1092449172), we will improve this behavior in future versions.
-
-
-
-
-

content/docs/for-app-developers/how-to/special-cases/use-http-proxy.md

@@ -17,10 +17,10 @@ We show how to solve both of these constraints.
 
 ## Making `pack` Proxy Aware
 
-You may need the `pack` command-line tool to download buildpacks and images via your proxy.  Building an application with an incorrectly configured proxy results in errors such as the following:
+You may need the `pack` command-line tool to download buildpacks and images via your proxy. Building an application with an incorrectly configured proxy results in errors such as the following:
 
 ```console
-$ pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:jammy
+$ pack build sample-app --path samples/apps/java-maven --builder docker.io/cnbs/sample-builder:jammy
 ERROR: failed to build: failed to fetch builder image 'index.docker.io/cnbs/sample-builder:jammy'
 : Error response from daemon: Get "https//registry-1.docker.io/v2/": context deadline exceeded
 ```
@@ -38,10 +38,10 @@ The Docker project documents [how to configure configure the HTTP/HTTPS proxy](h
 
 Buildpacks may also need to be aware of your http and https proxies at build time.  For example python, java and nodejs buildpacks need to be aware of proxies in order to resolve dependencies.  To make buildpacks aware of proxies, export the `http_proxy` and `https_proxy` environment variables before invoking `pack`.  For example:
 
-```console
+```
 export http_proxy=http://user:[email protected]:3128
 export https_proxy=https://my-proxy.example.com:3129
-pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:jammy
+pack build sample-app --path samples/apps/java-maven --builder docker.io/cnbs/sample-builder:jammy
 ```
 
 ## Making your Application Proxy Aware

content/docs/for-app-developers/tutorials/basic-app/_index.md

@@ -41,12 +41,12 @@ ls samples || git clone https://github.com/buildpacks/samples
 
 2. Build the app
 ```
-pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:jammy
+pack build sample-app --path samples/apps/java-maven --builder docker.io/cnbs/sample-builder:jammy
 ```
 <!--+- "{{execute}}"+-->
 
 > **TIP:** If you don't want to keep specifying a builder every time you build, you can set it as your default
-> builder by running `pack config default-builder <BUILDER>` for example `pack config default-builder cnbs/sample-builder:jammy`
+> builder by running `pack config default-builder <BUILDER>` for example `pack config default-builder docker.io/cnbs/sample-builder:jammy`
 <!--+- "{{execute}}"+-->
 
 ### 3. Run it

content/docs/for-platform-operators/how-to/build-inputs/create-builder/build-base.md

@@ -17,7 +17,7 @@ We need a Dockerfile similar to the following:
 
 ```Dockerfile
 # Define the base image
-FROM ubuntu:jammy
+FROM docker.io/ubuntu:jammy
 
 # Install packages that we want to make available at build time
 RUN apt-get update && \
@@ -71,5 +71,5 @@ To determine which values to provide, see [targets](/docs/for-buildpack-authors/
 ## Build the build base image
 
 ```bash
-docker build . -t cnbs/sample-base-build:jammy
+docker build . -t docker.io/cnbs/sample-base-build:jammy
 ```