0.7.0 release docs

Signed-off-by: ashnamehrotra <[email protected]>

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

@@ -0,0 +1,21 @@
+---
+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.
+
+### Static Incremental Tags
+The first approach you could take is incrementing a number you append to the end of an image tag. For example, if you have an image tagged `nginx:1.24.0`, following patches would be tagged as `nginx:1.24.0-1`, `nginx:1.24.0-2`, `nginx:1.24.0-3`, and so on.
+
+With this pattern you are always explicitly aware of the patch state of the image you are using. The downside is that dependabot is currently unable bump to patched images from unmodified images or bump from one patched image to the next.
+
+### 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.

website/versioned_docs/version-v0.7.x/code-of-conduct.md

@@ -0,0 +1,87 @@
+---
+title: Code of Conduct
+---
+
+# CNCF Community Code of Conduct v1.3
+
+### Community Code of Conduct
+
+As contributors, maintainers, and participants in the CNCF community, and in the interest of fostering
+an open and welcoming community, we pledge to respect all people who participate or contribute
+through reporting issues, posting feature requests, updating documentation,
+submitting pull requests or patches, attending conferences or events, or engaging in other community or project activities.
+
+We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of age, body size, caste, disability, ethnicity, level of experience, family status, gender, gender identity and expression, marital status, military or veteran status, nationality, personal appearance, race, religion, sexual orientation, socioeconomic status, tribe, or any other dimension of diversity.
+
+## Scope
+
+This code of conduct applies:
+* within project and community spaces,
+* in other spaces when an individual CNCF community participant's words or actions are directed at or are about a CNCF project, the CNCF community, or another CNCF community participant.
+
+### CNCF Events
+
+CNCF events that are produced by the Linux Foundation with professional events staff are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct.
+
+## Our Standards
+
+The CNCF Community is open, inclusive and respectful. Every member of our community has the right to have their identity respected.
+
+Examples of behavior that contributes to a positive environment include but are not limited to:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+* Using welcoming and inclusive language
+
+
+Examples of unacceptable behavior include but are not limited to:
+
+* The use of sexualized language or imagery
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment in any form
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Violence, threatening violence, or encouraging others to engage in violent behavior
+* Stalking or following someone without their consent
+* Unwelcome physical contact
+* Unwelcome sexual or romantic attention or advances
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+The following behaviors are also prohibited:
+* Providing knowingly false or misleading information in connection with a Code of Conduct investigation or otherwise intentionally tampering with an investigation.
+* Retaliating against a person because they reported an incident or provided information about an incident as a witness.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.
+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
+of managing a CNCF project.
+Project maintainers who do not follow or enforce the Code of Conduct may be temporarily or permanently removed from the project team.
+
+## Reporting
+
+For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via [[email protected]](mailto:[email protected]). You can expect a response within three business days.
+
+For other projects, or for incidents that are project-agnostic or impact multiple CNCF projects, please contact the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) via [[email protected]](mailto:[email protected]).  Alternatively, you can contact any of the individual members of the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) to submit your report. For more detailed instructions on how to submit a report, including how to submit a report anonymously, please see our [Incident Resolution Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md). You can expect a response within three business days.
+
+For incidents occurring at CNCF event that is produced by the Linux Foundation, please contact [[email protected]](mailto:[email protected]).
+
+## Enforcement
+
+Upon review and investigation of a reported incident, the CoC response team that has jurisdiction will determine what action is appropriate based on this Code of Conduct and its related documentation.
+
+For information about which Code of Conduct incidents are handled by project leadership, which incidents are handled by the CNCF Code of Conduct Committee, and which incidents are handled by the Linux Foundation (including its events team), see our [Jurisdiction Policy](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md).
+
+## Amendments
+
+Consistent with the CNCF Charter, any substantive changes to this Code of Conduct must be approved by the Technical Oversight Committee.
+
+## Acknowledgements
+
+This Code of Conduct is adapted from the Contributor Covenant
+(http://contributor-covenant.org), version 2.0 available at
+http://contributor-covenant.org/version/2/0/code_of_conduct/

website/versioned_docs/version-v0.7.x/contributing.md

@@ -0,0 +1,143 @@
+---
+title: Contributing
+---
+
+Welcome! We are very happy to accept community contributions to the project, whether through [filing issues](#contributing-issues) or [code](#contributing-code) in the form of [Pull Requests](#pull-requests). Please note that by participating in this project, you agree to abide by the [Code of Conduct](./code-of-conduct.md), as well as the terms of the [Developer Certificate of Origin](#developer-certificate-of-origin-dco).
+
+## Bi-Weekly Community Meeting
+A great way to get started is to join our bi-weekly community meeting. The meeting is held every other Monday from 1:30pm PT - 2:15pm PT. You can find the agenda and links to join [here](https://docs.google.com/document/d/1QdskbeCtgKcdWYHI6EXkLFxyzTCyVT6e8MgB3CaAhWI/edit?usp=sharing)
+
+## Slack
+To discuss issues with Copa, features, or development, you can join the [`#copacetic`](https://cloud-native.slack.com/archives/C071UU5QDKJ) channel on the [CNCF Slack](https://communityinviter.com/apps/cloud-native/cncf).
+
+## Contributing Issues
+
+Before opening any new issues, please search our [existing GitHub issues](https://github.com/project-copacetic/copacetic/issues) to check if your bug or suggestion has already been filed. If such an issue already exists, we recommend adding your comments and perspective to that existing issue instead.
+
+When opening an issue, please select the most appropriate template for what you're contributing:
+
+* **Bug Report:** If you would like to report the project or tool behaving in unexpected ways.
+* **Documentation Improvement:** If you have corrections or improvements to the project's documents, be they typos, factual errors, or missing content.
+* **Request:** If you have a feature request, suggestion, or a even a design proposal to review.
+* **Question:** If you would like to ask the maintainers a question about the project.
+
+## Contributing Code
+
+### Getting Started
+
+Follow the instructions to set up your dev environment to build Copacetic.
+
+For an overview of the project components, refer to the [Copa design](./design.md) document.
+
+### IDE Setup
+
+Copacetic is written in Go, so any IDE that supports Go may be used. If you have an IDE you prefer, simply search for a guide to set it up with Go. If you don't have a preferred IDE or if you're a new developer, some popular options are listed below:
+
+* [GoLand](https://www.jetbrains.com/help/go/quick-start-guide-goland.html)
+* [VSCode](https://code.visualstudio.com/docs/languages/go)
+* [Vim](https://github.com/fatih/vim-go)
+* [Zed](https://zed.dev/docs/languages/go)
+
+After choosing your IDE, we should install [gofumpt](https://github.com/mvdan/gofumpt). It's a stricter formatter than `gofmt` which Copacetic requires to pass all tests. Once installed, you may optionally set it up to run in your IDE of choice by following the instructions about halfway down the page.
+
+### Docker Setup
+
+Copacetic requires Docker for patching images. To install Docker, follow the [Docker installation guide](https://docs.docker.com/engine/install/).
+
+### Tests
+
+Once you can successfully `make` the project, any code contributions should also successfully:
+
+* Pass unit tests via `make test`.
+* Lint cleanly via `make lint`.
+* Be formatted with `gofumpt`.
+
+Pull requests will also be expected to pass the PR functional tests specified by `.github/workflows/build.yml`.
+
+### Pull Requests
+
+If you'd like to start contributing code to the project, you can search for [issues with the `good first issue` label](https://github.com/project-copacetic/copacetic/labels/good%20first%20issue). Other kinds of PR contributions we would look for include:
+
+* Fixes for bugs and other correctness issues.
+* Docs and other content improvements (e.g. samples).
+* Extensions to support parsing new scanning report formats.
+* Extensions to support patching images based on new distros or using new package managers.
+
+For any changes that may involve significant refactoring or development effort, we suggest that you file an issue to discuss the proposal with the maintainers first as it is unlikely that we will accept large PRs without prior discussion that have:
+
+* Architectural changes (e.g. breaking interfaces or violations of [this project's design tenets](./design.md#design-tenets)).
+* Unsolicited features that significantly expand the functional scope of the tool.
+
+Pull requests should be submitted from your fork of the project with the PR template filled out. This project uses the [Angular commit message format](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format) for automated changelog generation, so it's helpful to be familiar with it as the maintainers will need to ensure adherence to it on accepting PRs.
+
+We suggest:
+
+* Use the standard header format of `"<type>: <short summary>"` where the `<type>` is one of the following:
+  * **build:** Changes that affect the build system or external dependencies
+  * **ci:** Changes to the GitHub workflows and configurations
+  * **docs:** Documentation only changes
+  * **feat:** A new feature
+  * **fix:** A bug fix
+  * **perf:** A code change that improves performance
+  * **refactor:** A code change that neither fixes a bug nor adds a feature
+  * **test:** Adding missing tests or correcting existing tests
+* Use a [concise, imperative description](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) of the changes included in the `<short summary>` of the header, the body of the PR, and generally in your commit messages.
+* Use [GitHub keywords](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests) in the footer of your PR description, such as `closes` to automatically close issues the PR intends to address.
+
+## Developer Certificate of Origin (DCO)
+
+The [Developer Certificate of Origin](https://wiki.linuxfoundation.org/dco) (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the [full text of the DCO](https://developercertificate.org/), reformatted for readability:
+
+> By making a contribution to this project, I certify that:
+>
+> (a) The contribution was created in whole or in part by me and I
+> have the right to submit it under the open source license
+> indicated in the file; or
+>
+> (b) The contribution is based upon previous work that, to the best
+> of my knowledge, is covered under an appropriate open source
+> license and I have the right under that license to submit that
+> work with modifications, whether created in whole or in part
+> by me, under the same open source license (unless I am
+> permitted to submit under a different license), as indicated
+> in the file; or
+>
+> (c) The contribution was provided directly to me by some other
+> person who certified (a), (b) or (c) and I have not modified
+> it.
+>
+> (d) I understand and agree that this project and the contribution
+> are public and that a record of the contribution (including all
+> personal information I submit with it, including my sign-off) is
+> maintained indefinitely and may be redistributed consistent with
+> this project or the open source license(s) involved.
+
+Contributors _sign-off_ that they adhere to these requirements by adding a `Signed-off-by` line to commit messages.
+
+```text
+This is my commit message
+
+Signed-off-by: Random J Developer <[email protected]>
+```
+
+Git even has a `-s` command line option to append this automatically to your commit message:
+
+```bash
+git commit -s -m 'This is my commit message'
+```
+
+Pull requests that do not contain a valid `Signed-off-by` line cannot be merged.
+
+### I didn't sign my commit, now what?
+
+No worries - You can easily amend your commit with a sign-off and force push the change to your submitting branch:
+
+```bash
+git switch <branch-name>
+git commit --amend --no-edit --signoff
+git push --force-with-lease <remote-name> <branch-name>
+```
+
+## Code of Conduct
+
+This project has adopted the [CNCF Code of Conduct](./code-of-conduct.md)

website/versioned_docs/version-v0.7.x/custom-address.md

@@ -0,0 +1,94 @@
+---
+title: Custom buildkit addresses
+---
+
+You may need to specify a custom address using the `--addr` flag. Here are the supported formats:
+
+- `unix:///path/to/buildkit.sock` - Connect to buildkit over unix socket.
+- `tcp://$BUILDKIT_ADDR:$PORT` - Connect to buildkit over TCP. (not recommended for security reasons)
+- `docker://<docker connection spec>` - Connect to docker, currently only unix sockets are supported, e.g. `docker://unix:///var/run/docker.sock` (or just `docker://`).
+- `docker-container://my-buildkit-container` - Connect to a buildkitd running in a docker container.
+- `buildx://my-builder` - Connect to a buildx builder (or `buildx://` for the currently selected builder). *Note: only container-backed buildx instances are currently supported*
+- `nerdctl-container://my-container-name` - Similar to `docker-container` but uses `nerdctl`.
+- `podman-container://my-container-name` - Similar to `docker-container` but uses `podman`.
+- `ssh://myhost` - Connect to a buildkit instance over SSH. Format of the host spec should mimic the SSH command.
+- `kubepod://mypod` - Connect to buildkit running in a Kubernetes pod. Can also specify kubectl context and pod namespace (`kubepod://mypod?context=foo&namespace=notdefault`).
+
+## Buildkit Connection Examples
+
+### Option 1: Connect using defaults
+```bash
+copa patch -i docker.io/library/nginx:1.21.6 -r nginx.1.21.6.json -t 1.21.6-patched
+```
+
+### Option 2: Connect to buildx
+
+```bash
+docker buildx create --name demo
+copa patch -i docker.io/library/nginx:1.21.6 -r nginx.1.21.6.json -t 1.21.6-patched --addr buildx://demo
+```
+
+### Option 3: Buildkit in a container
+
+```bash
+export BUILDKIT_VERSION=v0.12.4
+docker run \
+    --detach \
+    --rm \
+    --privileged \
+    --name buildkitd \
+    --entrypoint buildkitd \
+    "moby/buildkit:$BUILDKIT_VERSION"
+
+copa patch -i docker.io/library/nginx:1.21.6 -r nginx.1.21.6.json -t 1.21.6-patched --addr docker-container://buildkitd
+```
+
+### Option 4: Buildkit over TCP
+```bash
+export BUILDKIT_VERSION=v0.12.4
+export BUILDKIT_PORT=8888
+docker run \
+    --detach \
+    --rm \
+    --privileged \
+    -p 127.0.0.1:$BUILDKIT_PORT:$BUILDKIT_PORT/tcp \
+    --name buildkitd \
+    --entrypoint buildkitd \
+    "moby/buildkit:$BUILDKIT_VERSION" \
+    --addr tcp://0.0.0.0:$BUILDKIT_PORT
+
+copa patch \
+    -i docker.io/library/nginx:1.21.6 \
+    -r nginx.1.21.6.json \
+    -t 1.21.6-patched \
+    -a tcp://0.0.0.0:$BUILDKIT_PORT
+```
+
+### Option 5: Buildkit over TCP with mTLS
+
+```bash
+export BUILDKIT_VERSION=v0.12.4
+export BUILDKIT_PORT=8888
+docker run \
+    --detach \
+    --rm \
+    --privileged \
+    -p 127.0.0.1:$BUILDKIT_PORT:$BUILDKIT_PORT/tcp \
+    --name buildkitd \
+    --entrypoint buildkitd \
+    -v $PWD/.certs:/etc/buildkit/certs \
+    "moby/buildkit:$BUILDKIT_VERSION" \
+    --addr tcp://0.0.0.0:$BUILDKIT_PORT \
+    --tlscacert /etc/buildkit/certs/daemon/ca.pem \
+    --tlscert /etc/buildkit/certs/daemon/cert.pem \
+    --tlskey /etc/buildkit/certs/daemon/key.pem
+
+copa patch \
+    -i docker.io/library/nginx:1.21.6 \
+    -r nginx.1.21.6.json \
+    -t 1.21.6-patched \
+    -a tcp://0.0.0.0:$BUILDKIT_PORT
+    --cacert /path/to/ca-certificate \
+    --cert  /path/to/buildkit/client/cert \
+    --key /path/to/buildkit/key
+```