docs: add documentation for dependabot and copa (#801)

Signed-off-by: ashnamehrotra <ashnamehrotra@gmail.com>

website/docs/best-practices.md

@@ -4,9 +4,6 @@ title: Tagging Guidelines
 
 There are some patterns and practices you may want to consider when using Copa to patch images. Remember that these are suggestions that may not fit into your workflow, but we think that staying as close as possible to these practices offers the best experience with Copa.
 
-## Patch from Unmodified image
-When patching vulnerabilities in an image, it helps to always work from the initial unmodified image. For example, say you have an image tagged `nginx:1.24.0` that contains a vulnerability. You run Copa to patch the image and produce a new image tagged `nginx:1.24.0-1`. Then if another vulnerability shows up in your `nginx:1.24.0-1` image, you should again patch from the unmodified `nginx:1.24.0` image. This will help prevent the buildup of patch layers ([discarding subsequent patch layers](https://github.com/project-copacetic/copacetic/issues/389) is a potential future enhancement).
-
 ## Tagging
 There are a couple possible patterns that you could follow when tagging patched images.
 
@@ -18,4 +15,11 @@ With this pattern you are always explicitly aware of the patch state of the imag
 ### Dynamic Tags
 Another option is a static tag that is continually reused as new patches are applied. For example, you could have an initial unmodified image that you've tagged `nginx:1.24.0-0` (in this case the `-0` at the end helps identify the base unpatched image). All following patched images are then tagged as `nginx:1.24.0`. You then know that the one tagged image always has the latest patches applied.
 
-This method makes it easy to continually consume the latest patched version of an image, but does contain some tradeoffs. First is that without pinning, image digests could change causing unpredictable behavior. Secondly, if an `ImagePullPolicy` is set to `IfNotPresent`, newly patched images would not be pulled since the tag hasn't changed.
+This method makes it easy to continually consume the latest patched version of an image, but does contain some tradeoffs. First is that without pinning, image digests could change causing unpredictable behavior. Secondly, if an `ImagePullPolicy` is set to `IfNotPresent`, newly patched images would not be pulled since the tag hasn't changed.
+
+### Dependabot
+[Dependabot](https://docs.github.com/en/code-security/dependabot) can create PRs to update image versions to Copa patched versions.
+
+- By default, if no update type is specified, Dependabot will be able to bump from a non-revision version to a revisioned version of an image if it exists. For example from `1.2.3` -> `1.2.3-1`.
+- If update type is restricted to patch only, the version would be updated to the patched version unless a minor version exists. For example, `1.2.3` would be updated to `1.2.3-1` and keep bumping revisions (`1.2.3-1 -> 1.2.3-2` etc.) over `1.3.0` or `2.0`. If `1.2.4` exists, however, it would be updated to `1.2.4` instead.
+- If patched at build time, Dependabot should pick up the revision of the patch version (`1.2.3-2` -> `1.2.4` -> `1.2.4-1`) to minimize regressions.

website/docs/faq.md

@@ -70,3 +70,9 @@ export EXPERIMENTAL_BUILDKIT_SOURCE_POLICY=source-policy.json
 > The tooling image for Debian-based images can be `docker.io/library/debian:11-slim` or `docker.io/library/debian:12-slim` depending on the target image version. RPM-based repos use `mcr.microsoft.com/cbl-mariner/base/core:2.0`.
 
 For more information on source policies, see [Buildkit Source Policies](https://docs.docker.com/build/building/env-vars/#experimental_buildkit_source_policy).
+
+## Can I use Dependabot with Copa patched images?
+Yes, see [best practices](best-practices.md#dependabot) to learn more about using Dependabot with Copa patched images.
+
+## Does Copa cause a buildup of patched layers on each patch?
+No. To prevent a buildup of layers, Copa discards the previous patch layer with each new patch. Each subsequent patch removes the earlier patch layer and creates a new one, which includes all patches applied since the original base image Copa started with. Essentially, Copa is creating a new layer with the latest patch, based on the base/original image. This new layer is a combination (or squash) of both the previous updates and the new updates requested. Discarding the patch layer also reduces the size of the resulting patched images in the future.

website/versioned_docs/version-v0.8.x/best-practices.md

@@ -4,9 +4,6 @@ title: Tagging Guidelines
 
 There are some patterns and practices you may want to consider when using Copa to patch images. Remember that these are suggestions that may not fit into your workflow, but we think that staying as close as possible to these practices offers the best experience with Copa.
 
-## Patch from Unmodified image
-When patching vulnerabilities in an image, it helps to always work from the initial unmodified image. For example, say you have an image tagged `nginx:1.24.0` that contains a vulnerability. You run Copa to patch the image and produce a new image tagged `nginx:1.24.0-1`. Then if another vulnerability shows up in your `nginx:1.24.0-1` image, you should again patch from the unmodified `nginx:1.24.0` image. This will help prevent the buildup of patch layers ([discarding subsequent patch layers](https://github.com/project-copacetic/copacetic/issues/389) is a potential future enhancement).
-
 ## Tagging
 There are a couple possible patterns that you could follow when tagging patched images.
 
@@ -18,4 +15,11 @@ With this pattern you are always explicitly aware of the patch state of the imag
 ### Dynamic Tags
 Another option is a static tag that is continually reused as new patches are applied. For example, you could have an initial unmodified image that you've tagged `nginx:1.24.0-0` (in this case the `-0` at the end helps identify the base unpatched image). All following patched images are then tagged as `nginx:1.24.0`. You then know that the one tagged image always has the latest patches applied.
 
-This method makes it easy to continually consume the latest patched version of an image, but does contain some tradeoffs. First is that without pinning, image digests could change causing unpredictable behavior. Secondly, if an `ImagePullPolicy` is set to `IfNotPresent`, newly patched images would not be pulled since the tag hasn't changed.
+This method makes it easy to continually consume the latest patched version of an image, but does contain some tradeoffs. First is that without pinning, image digests could change causing unpredictable behavior. Secondly, if an `ImagePullPolicy` is set to `IfNotPresent`, newly patched images would not be pulled since the tag hasn't changed.
+
+### Dependabot
+[Dependabot](https://docs.github.com/en/code-security/dependabot) can create PRs to update image versions to Copa patched versions.
+
+- By default, if no update type is specified, Dependabot will be able to bump from a non-revision version to a revisioned version of an image if it exists. For example from `1.2.3` -> `1.2.3-1`.
+- If update type is restricted to patch only, the version would be updated to the patched version unless a minor version exists. For example, `1.2.3` would be updated to `1.2.3-1` and keep bumping revisions (`1.2.3-1 -> 1.2.3-2` etc.) over `1.3.0` or `2.0`. If `1.2.4` exists, however, it would be updated to `1.2.4` instead.
+- If patched at build time, Dependabot should pick up the revision of the patch version (`1.2.3-2` -> `1.2.4` -> `1.2.4-1`) to minimize regressions.

website/versioned_docs/version-v0.8.x/faq.md

@@ -70,3 +70,6 @@ export EXPERIMENTAL_BUILDKIT_SOURCE_POLICY=source-policy.json
 > The tooling image for Debian-based images can be `docker.io/library/debian:11-slim` or `docker.io/library/debian:12-slim` depending on the target image version. RPM-based repos use `mcr.microsoft.com/cbl-mariner/base/core:2.0`.
 
 For more information on source policies, see [Buildkit Source Policies](https://docs.docker.com/build/building/env-vars/#experimental_buildkit_source_policy).
+
+## Does Copa cause a buildup of patched layers on each patch?
+No. To prevent a buildup of layers, Copa discards the previous patch layer with each new patch. Each subsequent patch removes the earlier patch layer and creates a new one, which includes all patches applied since the original base image Copa started with. Essentially, Copa is creating a new layer with the latest patch, based on the base/original image. This new layer is a combination (or squash) of both the previous updates and the new updates requested. Discarding the patch layer also reduces the size of the resulting patched images in the future.