Do not reference CNAB invocation images

As CNAB is an implementation detail as this point, we no longer want
to use the term 'invocation image'. Instead we should use the term
'bundle image'.
This PR ensures that the current references to 'invocation image' is
changed to 'bundle image'.

Signed-off-by: Kim Christensen <kimworking@gmail.com>

CONTRIBUTING.md

@@ -573,7 +573,7 @@ dependency injection and testing strategies.
   this repository
 * **docs**: our website
 * **pkg**
-  * **build**: implements building the invocation image.
+  * **build**: implements building the bundle image.
   * **cache**: handles the cache of bundles that have been pulled by commands
   like `porter install --reference`.
   * **cnab**: deals with the CNAB spec

cmd/exec/build.go

@@ -10,7 +10,7 @@ import (
 func buildBuildCommand(m *exec.Mixin) *cobra.Command {
 	cmd := &cobra.Command{
 		Use:   "build",
-		Short: "Generate Dockerfile lines for the bundle invocation image",
+		Short: "Generate Dockerfile lines for the bundle image",
 		Run: func(cmd *cobra.Command, args []string) {
 			fmt.Fprintln(m.Config.Out, "# exec mixin has no buildtime dependencies")
 		},

cmd/porter/bundle.go

@@ -53,7 +53,7 @@ func buildBundleBuildCommand(p *porter.Porter) *cobra.Command {
 	cmd := &cobra.Command{
 		Use:   "build",
 		Short: "Build a bundle",
-		Long: `Builds the bundle in the current directory by generating a Dockerfile and a CNAB bundle.json, and then building the invocation image.
+		Long: `Builds the bundle in the current directory by generating a Dockerfile and a CNAB bundle.json, and then building the bundle image.
 
 The docker driver builds the bundle image using the local Docker host. To use a remote Docker host, set the following environment variables:
   DOCKER_HOST (required)
@@ -85,7 +85,7 @@ The docker driver builds the bundle image using the local Docker host. To use a
 	f.StringVarP(&opts.Dir, "dir", "d", "",
 		"Path to the build context directory where all bundle assets are located. Defaults to the current directory.")
 	f.StringVar(&opts.Driver, "driver", porter.BuildDriverDefault,
-		fmt.Sprintf("Driver for building the invocation image. Allowed values are: %s", strings.Join(porter.BuildDriverAllowedValues, ", ")))
+		fmt.Sprintf("Driver for building the bundle image. Allowed values are: %s", strings.Join(porter.BuildDriverAllowedValues, ", ")))
 	_ = f.MarkHidden("driver") // Hide the driver flag since there aren't any choices to make right now
 	f.StringArrayVar(&opts.BuildArgs, "build-arg", nil,
 		"Set build arguments in the template Dockerfile (format: NAME=VALUE). May be specified multiple times. Max length is 5,000 characters.")
@@ -94,7 +94,7 @@ The docker driver builds the bundle image using the local Docker host. To use a
 	f.StringArrayVar(&opts.Secrets, "secret", nil,
 		"Secret file to expose to the build (format: id=mysecret,src=/local/secret). Custom values are accessible as build arguments in the template Dockerfile and in the manifest using template variables. May be specified multiple times.")
 	f.BoolVar(&opts.NoCache, "no-cache", false,
-		"Do not use the Docker cache when building the bundle's invocation image.")
+		"Do not use the Docker cache when building the bundle image.")
 	f.StringArrayVar(&opts.Customs, "custom", nil,
 		"Define an individual key-value pair for the custom section in the form of NAME=VALUE. Use dot notation to specify a nested custom field. May be specified multiple times. Max length is 5,000 characters when used as a build argument.")
 	f.BoolVar(&opts.InsecureRegistry, "insecure-registry", false,
@@ -143,9 +143,9 @@ func buildBundlePublishCommand(p *porter.Porter) *cobra.Command {
 	cmd := cobra.Command{
 		Use:   "publish",
 		Short: "Publish a bundle",
-		Long: `Publishes a bundle by pushing the invocation image and bundle to a registry.
+		Long: `Publishes a bundle by pushing the bundle image and bundle to a registry.
 
-Note: if overrides for registry/tag/reference are provided, this command only re-tags the invocation image and bundle; it does not re-build the bundle.`,
+Note: if overrides for registry/tag/reference are provided, this command only re-tags the bundle image and bundle; it does not re-build the bundle.`,
 		Example: `  porter bundle publish
   porter bundle publish --file myapp/porter.yaml
   porter bundle publish --dir myapp
@@ -188,7 +188,7 @@ func buildBundleArchiveCommand(p *porter.Porter) *cobra.Command {
 	cmd := cobra.Command{
 		Use:   "archive FILENAME --reference PUBLISHED_BUNDLE",
 		Short: "Archive a bundle from a reference",
-		Long:  "Archives a bundle by generating a gzipped tar archive containing the bundle, invocation image and any referenced images.",
+		Long:  "Archives a bundle by generating a gzipped tar archive containing the bundle, bundle image and any referenced images.",
 		Example: `  porter bundle archive mybun.tgz --reference ghcr.io/getporter/examples/porter-hello:v0.2.0
   porter bundle archive mybun.tgz --reference localhost:5000/ghcr.io/getporter/examples/porter-hello:v0.2.0 --force
   porter bundle archive mybun.tgz --compression NoCompression --reference ghcr.io/getporter/examples/porter-hello:v0.2.0

cmd/porter/inspect.go

@@ -10,7 +10,7 @@ func buildBundleInspectCommand(p *porter.Porter) *cobra.Command {
 	cmd := cobra.Command{
 		Use:   "inspect REFERENCE",
 		Short: "Inspect a bundle",
-		Long: `Inspect a bundle by printing the invocation images and any related images images.
+		Long: `Inspect a bundle by printing the bundle images and any related images images.
 
 If you would like more information about the bundle, the porter explain command will provide additional information,
 like parameters, credentials, outputs and custom actions available.

cmd/porter/installations.go

@@ -224,7 +224,7 @@ The first argument is the name of the installation to create. This defaults to t
 
 Once a bundle has been successfully installed, the install action cannot be repeated. This is a precaution to avoid accidentally overwriting an existing installation. If you need to re-run install, which is common when authoring a bundle, you can use the --force flag to by-pass this check.
 
-Porter uses the docker driver as the default runtime for executing a bundle's invocation image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
+Porter uses the docker driver as the default runtime for executing a bundle image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
 For example, the 'debug' driver may be specified, which simply logs the info given to it and then exits.
 
 The docker driver runs the bundle container using the local Docker host. To use a remote Docker host, set the following environment variables:
@@ -274,7 +274,7 @@ func buildInstallationUpgradeCommand(p *porter.Porter) *cobra.Command {
 
 The first argument is the installation name to upgrade. This defaults to the name of the bundle.
 
-Porter uses the docker driver as the default runtime for executing a bundle's invocation image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
+Porter uses the docker driver as the default runtime for executing a bundle image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
 For example, the 'debug' driver may be specified, which simply logs the info given to it and then exits.
 
 The docker driver runs the bundle container using the local Docker host. To use a remote Docker host, set the following environment variables:
@@ -322,7 +322,7 @@ func buildInstallationInvokeCommand(p *porter.Porter) *cobra.Command {
 
 The first argument is the installation name upon which to invoke the action. This defaults to the name of the bundle.
 
-Porter uses the docker driver as the default runtime for executing a bundle's invocation image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
+Porter uses the docker driver as the default runtime for executing a bundle image, but an alternate driver may be supplied via '--driver/-d' or the PORTER_RUNTIME_DRIVER environment variable.
 For example, the 'debug' driver may be specified, which simply logs the info given to it and then exits.
 
 The docker driver runs the bundle container using the local Docker host. To use a remote Docker host, set the following environment variables:
@@ -370,7 +370,7 @@ func buildInstallationUninstallCommand(p *porter.Porter) *cobra.Command {
 
 The first argument is the installation name to uninstall. This defaults to the name of the bundle.
 
-Porter uses the docker driver as the default runtime for executing a bundle's invocation image, but an alternate driver may be supplied via '--driver/-d'' or the PORTER_RUNTIME_DRIVER environment variable.
+Porter uses the docker driver as the default runtime for executing a bundle image, but an alternate driver may be supplied via '--driver/-d'' or the PORTER_RUNTIME_DRIVER environment variable.
 For example, the 'debug' driver may be specified, which simply logs the info given to it and then exits.
 
 The docker driver runs the bundle container using the local Docker host. To use a remote Docker host, set the following environment variables:

docs/content/architecture-buildtime.md

@@ -18,7 +18,7 @@ Mixins are cached in your PORTER_HOME directory, and the kubernetes mixin can be
 Porter does not support specifying which version of a mixin to use in a bundle yet.
 You can follow the [Mixins are Bundles proposal](https://github.com/getporter/proposals/blob/main/pep/005-mixins-are-bundles.md) to keep track of that feature's progress.
 
-When the bundle author runs `porter build`, Porter first generates a Dockerfile to create an image for the bundle (known as the invocation image or installer).
+When the bundle author runs `porter build`, Porter first generates a Dockerfile to create an image for the bundle (known as the bundle image or installer).
 You can define your own [custom Dockerfile](/docs/bundle/custom-dockerfile/) to customize and optimize the image.
 The Dockerfile contains the following: a base image (debian), additional customizations generated by the mixins, and a COPY statement to include the files contained in the bundle directory where the porter.yaml file is located.
 A copy of the Porter runtime, the mixin runtimes and the porter.yaml file are copied into the bundle.

docs/content/architecture-runtime.md

@@ -9,7 +9,7 @@ The "Porter runtime" specifically refers to the embedded copy of the porter-runt
 Below is an outline of what happens when a bundle is executed:
 
 1. Porter identifies all parameters and credentials, resolving parameter and credentials sets against the host environment and any configured secret stores.
-2. Porter runs a container using the bundle's invocation image, injecting the parameters and credentials as files and/or environment variables.
+2. Porter runs a container using the bundle image, injecting the parameters and credentials as files and/or environment variables.
 3. The entrypoint of the container is the Porter runtime. It parses the porter.yaml file embedded in the bundle, and executes the steps defined for the current action (such as install or upgrade).
 4. For each step, Porter calls the corresponding mixins which are also embedded in the bundle.
 5. The mixin performs an action, most commonly translating the yaml snippet for the step into a call to a development tool. For example, the helm3 mixin handles calling out to the helm CLI.

docs/content/archive-bundles.md

@@ -3,7 +3,7 @@ title: Archiving Bundles
 description: Archiving Bundles with Porter
 ---
 
-Porter allows you to share bundles by [publishing](/distributing-bundles/) them to an OCI registry. Porter also allows you to copy a bundle from one registry to another. Using these commands, bundle users have flexibility in how they leverage published bundles. What if you want to use a published bundle on a disconnected or edge network that has limited connectivity? The `porter archive` command and the `porter publish` commands allow you to take the bundle from a registry on one network, move it to the network or location, and republish it into another registry for use within that environment. The generated bundle archive contains the CNAB `bundle.json`, along with an OCI [image layout](https://github.com/opencontainers/image-spec/blob/master/image-layout.md) containing the invocation image and any images declared in the `images` section of the `bundle.json`. This enables the entire bundle to be easily moved into a private data center or across an air-gapped network, and republished within that environment.
+Porter allows you to share bundles by [publishing](/distributing-bundles/) them to an OCI registry. Porter also allows you to copy a bundle from one registry to another. Using these commands, bundle users have flexibility in how they leverage published bundles. What if you want to use a published bundle on a disconnected or edge network that has limited connectivity? The `porter archive` command and the `porter publish` commands allow you to take the bundle from a registry on one network, move it to the network or location, and republish it into another registry for use within that environment. The generated bundle archive contains the CNAB `bundle.json`, along with an OCI [image layout](https://github.com/opencontainers/image-spec/blob/master/image-layout.md) containing the bundle image and any images declared in the `images` section of the `bundle.json`. This enables the entire bundle to be easily moved into a private data center or across an air-gapped network, and republished within that environment.
 
 For a working example of how to move a bundle across an airgap, read [Example: Airgapped Environments](/examples/airgap/).
 
@@ -56,7 +56,7 @@ drwxr-xr-x  0 jeremyrickard staff       0 Oct 18 10:27 ./artifacts/layout/blobs/
 -rw-r--r--  0 jeremyrickard staff     2955 Oct 18 10:27 ./bundle.json
 ```
 
-In this archive file, you will see the `bundle.json`, along with all of the artifacts that represent the OCI image layout. In this case, we had two images, the invocation image and an application image. They are both written to the `artifacts/` directory as part of the OCI image layout.
+In this archive file, you will see the `bundle.json`, along with all of the artifacts that represent the OCI image layout. In this case, we had two images, the bundle image and an application image. They are both written to the `artifacts/` directory as part of the OCI image layout.
 
 ## Publish a Bundle Archive
 

docs/content/blog/migrate-from-docker-app.md

@@ -194,7 +194,7 @@ We will use the [docker-compose mixin] to migrate an existing Docker App to Port
 
     ```console
     $ porter publish
-    Pushing CNAB invocation image...
+    Pushing CNAB bundle image...
     The push refers to repository [docker.io/carolynvs/my-docker-app-installer]
     a5fd17ef8522: Preparing
     878a51fed4d7: Preparing

docs/content/design/kubernetes-mixin.md

@@ -15,7 +15,7 @@ In order to build a CNAB with the kubernetes mixin, the bundle author should pla
 
 ## Buildtime
 
-Rather than trying to rebuild the functionality of `kubectl`, this mixin will contribute lines to the invocation image Dockerfile that will result in `kubectl` being installed:
+Rather than trying to rebuild the functionality of `kubectl`, this mixin will contribute lines to the bundle image Dockerfile that will result in `kubectl` being installed:
 
 ```
 RUN apt-get update && \
@@ -57,7 +57,7 @@ The mixin allows bundle authors to specify the following parameters on install:
 
 ### Upgrade
 
- At runtime, the mixin will use the `kubectl apply` command when an `upgrade` action is specified. This will result in the resources defined in the supplied manifests being created or deleted, as appropriate. As the manifests will be contained within the bundle's invocation image, an upgrade action against an invocation image that was used for install is a no-op. The use of the `apply` command will allow the use of the `wait` flag The mixin will not support all of the [options](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) available, specifically `dry-run`, or options related to editing or deleting resources. Available parameters are spelled out below.
+ At runtime, the mixin will use the `kubectl apply` command when an `upgrade` action is specified. This will result in the resources defined in the supplied manifests being created or deleted, as appropriate. As the manifests will be contained within the bundle image, an upgrade action against an bundle image that was used for install is a no-op. The use of the `apply` command will allow the use of the `wait` flag The mixin will not support all of the [options](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) available, specifically `dry-run`, or options related to editing or deleting resources. Available parameters are spelled out below.
 
 | Parameter | Type | Description | Default |
 |-----------|------|-------------|---------|

docs/content/docs/administration/copy-bundles.md

@@ -6,7 +6,7 @@ aliases:
   - /copying-bundles/
 ---
 
-Porter allows you to copy a bundle, and all associated images, from one registry to another. This includes both the invocation images and the images defined in the `images` section of the bundle. For example, consider the following `images` map:
+Porter allows you to copy a bundle, and all associated images, from one registry to another. This includes both the bundle images and the images defined in the `images` section of the bundle. For example, consider the following `images` map:
 
 ```yaml
 images:
@@ -22,7 +22,7 @@ images:
     digest: "sha256:85b1a9b4b60a4cf73a23517dad677e64edf467107fa7d58fce9c50e6a3e4c914"
 ```
 
-When this bundle is copied, the invocation image, along with the `backend` and `websvc` images will be copied to the new repository. If the bundle author has properly used image [wiring](/wiring/#wiring-images), the new image references will be available within the bundle at run-time.
+When this bundle is copied, the bundle image, along with the `backend` and `websvc` images will be copied to the new repository. If the bundle author has properly used image [wiring](/wiring/#wiring-images), the new image references will be available within the bundle at run-time.
 
 This is useful when you have restrictions on where you can pull Docker images from or would otherwise like to have control over assets you will be using. Any operation on the copied bundle will utilize these copied images as well. IIf you'd like to rename something within a registry, Porter also allows you to copy from one bundle tag to another bundle tag inside the same registry.