Skip to content

Commit b89e7be

Browse files
github-actions[bot]ashnamehrotrasozercan
authored
chore: Generate v0.11.x docs (project-copacetic#1182)
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Sertaç Özercan <852750+sozercan@users.noreply.github.com> Co-authored-by: ashnamehrotra <26015861+ashnamehrotra@users.noreply.github.com> Co-authored-by: Sertaç Özercan <852750+sozercan@users.noreply.github.com>
1 parent b3ffe3a commit b89e7be

22 files changed

+1752
-0
lines changed
Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
title: Adopters
3+
---
4+
5+
Check out some adopters of Copa in the community:
6+
7+
### GitHub Actions Adopters
8+
- [Unoplat ](https://github.com/unoplat/unoplat/tree/develop)
9+
- [AKS Periscope](https://github.com/Azure/aks-periscope)
10+
- [Azure Workload](https://github.com/Azure/azure-workload-identity)
11+
- [AI Kit](https://github.com/sozercan/aikit)
12+
13+
---
14+
15+
### Copa CLI Adopters
16+
- [Helmper](https://github.com/ChristofferNissen/helmper)
17+
- [Kubescape](https://github.com/kubescape/kubescape)
18+
- [Devtron](https://docs.devtron.ai/usage/plugins/plugin-list/copacetic)
Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
title: Tagging Guidelines
3+
---
4+
5+
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.
6+
7+
## Tagging
8+
There are a couple possible patterns that you could follow when tagging patched images.
9+
10+
### Static Incremental Tags
11+
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.
12+
13+
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.
14+
15+
### Dynamic Tags
16+
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.
17+
18+
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.
19+
20+
### Dependabot
21+
[Dependabot](https://docs.github.com/en/code-security/dependabot) can create PRs to update image versions to Copa patched versions.
22+
23+
- 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`.
24+
- 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.
25+
- 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.
Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: Code of Conduct
3+
---
4+
5+
# CNCF Community Code of Conduct v1.3
6+
7+
### Community Code of Conduct
8+
9+
As contributors, maintainers, and participants in the CNCF community, and in the interest of fostering
10+
an open and welcoming community, we pledge to respect all people who participate or contribute
11+
through reporting issues, posting feature requests, updating documentation,
12+
submitting pull requests or patches, attending conferences or events, or engaging in other community or project activities.
13+
14+
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.
15+
16+
## Scope
17+
18+
This code of conduct applies:
19+
* within project and community spaces,
20+
* 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.
21+
22+
### CNCF Events
23+
24+
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.
25+
26+
## Our Standards
27+
28+
The CNCF Community is open, inclusive and respectful. Every member of our community has the right to have their identity respected.
29+
30+
Examples of behavior that contributes to a positive environment include but are not limited to:
31+
32+
* Demonstrating empathy and kindness toward other people
33+
* Being respectful of differing opinions, viewpoints, and experiences
34+
* Giving and gracefully accepting constructive feedback
35+
* Accepting responsibility and apologizing to those affected by our mistakes,
36+
and learning from the experience
37+
* Focusing on what is best not just for us as individuals, but for the
38+
overall community
39+
* Using welcoming and inclusive language
40+
41+
42+
Examples of unacceptable behavior include but are not limited to:
43+
44+
* The use of sexualized language or imagery
45+
* Trolling, insulting or derogatory comments, and personal or political attacks
46+
* Public or private harassment in any form
47+
* Publishing others' private information, such as a physical or email
48+
address, without their explicit permission
49+
* Violence, threatening violence, or encouraging others to engage in violent behavior
50+
* Stalking or following someone without their consent
51+
* Unwelcome physical contact
52+
* Unwelcome sexual or romantic attention or advances
53+
* Other conduct which could reasonably be considered inappropriate in a
54+
professional setting
55+
56+
The following behaviors are also prohibited:
57+
* Providing knowingly false or misleading information in connection with a Code of Conduct investigation or otherwise intentionally tampering with an investigation.
58+
* Retaliating against a person because they reported an incident or provided information about an incident as a witness.
59+
60+
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.
61+
By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
62+
of managing a CNCF project.
63+
Project maintainers who do not follow or enforce the Code of Conduct may be temporarily or permanently removed from the project team.
64+
65+
## Reporting
66+
67+
For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via [conduct@kubernetes.io](mailto:conduct@kubernetes.io). You can expect a response within three business days.
68+
69+
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 [conduct@cncf.io](mailto:conduct@cncf.io). 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.
70+
71+
For incidents occurring at CNCF event that is produced by the Linux Foundation, please contact [eventconduct@cncf.io](mailto:eventconduct@cncf.io).
72+
73+
## Enforcement
74+
75+
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.
76+
77+
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).
78+
79+
## Amendments
80+
81+
Consistent with the CNCF Charter, any substantive changes to this Code of Conduct must be approved by the Technical Oversight Committee.
82+
83+
## Acknowledgements
84+
85+
This Code of Conduct is adapted from the Contributor Covenant
86+
(http://contributor-covenant.org), version 2.0 available at
87+
http://contributor-covenant.org/version/2/0/code_of_conduct/
Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
---
2+
title: Contributing
3+
---
4+
5+
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).
6+
7+
## Bi-Weekly Community Meeting
8+
9+
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)
10+
11+
## Slack
12+
13+
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).
14+
15+
## Contributor Ladder
16+
17+
We have a contributor ladder that outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows.
18+
19+
For detailed information about contributor roles (Contributor, Reviewer, Maintainer) and how to advance through them, please see our [Contributor Ladder](https://github.com/project-copacetic/copacetic/blob/main/CONTRIBUTOR_LADDER.md).
20+
21+
## Contributing Issues
22+
23+
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.
24+
25+
When opening an issue, please select the most appropriate template for what you're contributing:
26+
27+
- **Bug Report:** If you would like to report the project or tool behaving in unexpected ways.
28+
- **Documentation Improvement:** If you have corrections or improvements to the project's documents, be they typos, factual errors, or missing content.
29+
- **Request:** If you have a feature request, suggestion, or a even a design proposal to review.
30+
- **Question:** If you would like to ask the maintainers a question about the project.
31+
32+
## Contributing Code
33+
34+
### Getting Started
35+
36+
Follow the instructions to set up your dev environment to build Copacetic.
37+
38+
For an overview of the project components, refer to the [Copa design](./design.md) document.
39+
40+
### IDE Setup
41+
42+
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:
43+
44+
- [GoLand](https://www.jetbrains.com/help/go/quick-start-guide-goland.html)
45+
- [VSCode](https://code.visualstudio.com/docs/languages/go)
46+
- [Vim](https://github.com/fatih/vim-go)
47+
- [Zed](https://zed.dev/docs/languages/go)
48+
49+
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.
50+
51+
### Docker Setup
52+
53+
Copacetic requires Docker for patching images. To install Docker, follow the [Docker installation guide](https://docs.docker.com/engine/install/).
54+
55+
### Tests
56+
57+
Once you can successfully `make` the project, any code contributions should also successfully:
58+
59+
- Pass unit tests via `make test`.
60+
- Lint cleanly via `make lint`.
61+
- Be formatted with `gofumpt`.
62+
63+
Pull requests will also be expected to pass the PR functional tests specified by `.github/workflows/build.yml`.
64+
65+
### Pull Requests
66+
67+
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:
68+
69+
- Fixes for bugs and other correctness issues.
70+
- Docs and other content improvements (e.g. samples).
71+
- Extensions to support parsing new scanning report formats.
72+
- Extensions to support patching images based on new distros or using new package managers.
73+
74+
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:
75+
76+
- Architectural changes (e.g. breaking interfaces or violations of [this project's design tenets](./design.md#design-tenets)).
77+
- Unsolicited features that significantly expand the functional scope of the tool.
78+
79+
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.
80+
81+
We suggest:
82+
83+
- Use the standard header format of `"<type>: <short summary>"` where the `<type>` is one of the following:
84+
- **build:** Changes that affect the build system or external dependencies
85+
- **ci:** Changes to the GitHub workflows and configurations
86+
- **docs:** Documentation only changes
87+
- **feat:** A new feature
88+
- **fix:** A bug fix
89+
- **perf:** A code change that improves performance
90+
- **refactor:** A code change that neither fixes a bug nor adds a feature
91+
- **test:** Adding missing tests or correcting existing tests
92+
- 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.
93+
- 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.
94+
95+
## Developer Certificate of Origin (DCO)
96+
97+
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:
98+
99+
> By making a contribution to this project, I certify that:
100+
>
101+
> (a) The contribution was created in whole or in part by me and I
102+
> have the right to submit it under the open source license
103+
> indicated in the file; or
104+
>
105+
> (b) The contribution is based upon previous work that, to the best
106+
> of my knowledge, is covered under an appropriate open source
107+
> license and I have the right under that license to submit that
108+
> work with modifications, whether created in whole or in part
109+
> by me, under the same open source license (unless I am
110+
> permitted to submit under a different license), as indicated
111+
> in the file; or
112+
>
113+
> (c) The contribution was provided directly to me by some other
114+
> person who certified (a), (b) or (c) and I have not modified
115+
> it.
116+
>
117+
> (d) I understand and agree that this project and the contribution
118+
> are public and that a record of the contribution (including all
119+
> personal information I submit with it, including my sign-off) is
120+
> maintained indefinitely and may be redistributed consistent with
121+
> this project or the open source license(s) involved.
122+
123+
Contributors _sign-off_ that they adhere to these requirements by adding a `Signed-off-by` line to commit messages.
124+
125+
```text
126+
This is my commit message
127+
128+
Signed-off-by: Random J Developer <random@developer.example.org>
129+
```
130+
131+
Git even has a `-s` command line option to append this automatically to your commit message:
132+
133+
```bash
134+
git commit -s -m 'This is my commit message'
135+
```
136+
137+
Pull requests that do not contain a valid `Signed-off-by` line cannot be merged.
138+
139+
### I didn't sign my commit, now what?
140+
141+
No worries - You can easily amend your commit with a sign-off and force push the change to your submitting branch:
142+
143+
```bash
144+
git switch <branch-name>
145+
git commit --amend --no-edit --signoff
146+
git push --force-with-lease <remote-name> <branch-name>
147+
```
148+
149+
## Code of Conduct
150+
151+
This project has adopted the [CNCF Code of Conduct](./code-of-conduct.md)

0 commit comments

Comments
 (0)