mirror of
https://github.com/kubeshark/kubeshark.git
synced 2025-09-13 13:22:01 +00:00
Move all docs to docs folder and clean project root (#278)
This commit is contained in:
4
.github/CODEOWNERS
vendored
4
.github/CODEOWNERS
vendored
@@ -1,4 +0,0 @@
|
||||
# This is a comment.
|
||||
# Each line is a file pattern followed by one or more owners.
|
||||
|
||||
/ui/ @frontend
|
76
.github/CODE_OF_CONDUCT.md
vendored
76
.github/CODE_OF_CONDUCT.md
vendored
@@ -1,76 +0,0 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as
|
||||
contributors and maintainers pledge to making participation in our project and
|
||||
our community a harassment-free experience for everyone, regardless of age, body
|
||||
size, disability, ethnicity, sex characteristics, gender identity and expression,
|
||||
level of experience, education, socio-economic status, nationality, personal
|
||||
appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment
|
||||
include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic
|
||||
address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable
|
||||
behavior and are expected to take appropriate and fair corrective action in
|
||||
response to any instances of unacceptable behavior.
|
||||
|
||||
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, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community. Examples of
|
||||
representing a project or community include using an official project e-mail
|
||||
address, posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event. Representation of a project may be
|
||||
further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting the project team at mizu@up9.com. All
|
||||
complaints will be reviewed and investigated and will result in a response that
|
||||
is deemed necessary and appropriate to the circumstances. The project team is
|
||||
obligated to maintain confidentiality with regard to the reporter of an incident.
|
||||
Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good
|
||||
faith may face temporary or permanent repercussions as determined by other
|
||||
members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
||||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
||||
For answers to common questions about this code of conduct, see
|
||||
https://www.contributor-covenant.org/faq
|
20
.github/CONTRIBUTING.md
vendored
20
.github/CONTRIBUTING.md
vendored
@@ -1,20 +0,0 @@
|
||||

|
||||
|
||||
# Contributing to Mizu
|
||||
|
||||
We welcome code contributions from the community.
|
||||
Please read and follow the guidelines below.
|
||||
|
||||
## Communication
|
||||
|
||||
* Before starting work on a major feature, please reach out to us via [GitHub](https://github.com/up9inc/mizu), [Slack](https://join.slack.com/share/zt-u6bbs3pg-X1zhQOXOH0yEoqILgH~csw), [email](mailto:mizu@up9.com), etc. We will make sure no one else is already working on it. A _major feature_ is defined as any change that is > 100 LOC altered (not including tests), or changes any user-facing behavior
|
||||
* Small patches and bug fixes don't need prior communication.
|
||||
|
||||
## Contribution Requirements
|
||||
|
||||
* Code style - most of the code is written in Go, please follow [these guidelines](https://golang.org/doc/effective_go)
|
||||
* Go-tools compatible (`go get`, `go test`, etc.)
|
||||
* Code coverage for unit tests must not decrease.
|
||||
* Code must be usefully commented. Not only for developers on the project, but also for external users of these packages
|
||||
* When reviewing PRs, you are encouraged to use Golang's [code review comments page](https://github.com/golang/go/wiki/CodeReviewComments)
|
||||
* Project follows [Google JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml) for the REST APIs that are provided.
|
33
.github/TESTING.md
vendored
33
.github/TESTING.md
vendored
@@ -1,33 +0,0 @@
|
||||

|
||||
# Testing guidelines
|
||||
|
||||
## Generic guidelines
|
||||
* Use "[testing](https://pkg.go.dev/testing)" package
|
||||
* Write [Table-driven tests using subtests](https://go.dev/blog/subtests)
|
||||
* Use cleanup in test/subtest in order to clean up resources
|
||||
* Name the test func "Test<tested_func_name><tested_case>"
|
||||
|
||||
## Unit tests
|
||||
* Position the test file inside the folder of the tested package
|
||||
* In case of internal func testing
|
||||
* Name the test file "<tested_file_name>_internal_test.go"
|
||||
* Name the test package same as the package being tested
|
||||
* Example - [Config](../cli/config/config_internal_test.go)
|
||||
* In case of exported func testing
|
||||
* Name the test file "<tested_file_name>_test.go"
|
||||
* Name the test package "<tested_package>_test"
|
||||
* Example - [Slice Utils](../cli/mizu/sliceUtils_test.go)
|
||||
* Make sure to run test coverage to make sure you covered all the cases and lines in the func
|
||||
|
||||
## Acceptance tests
|
||||
* Position the test file inside the [acceptance tests folder](../acceptanceTests)
|
||||
* Name the file "<tested_command>_test.go"
|
||||
* Name the package "acceptanceTests"
|
||||
* Do not run as part of the short tests
|
||||
* Use/Create generic test utils func in acceptanceTests/testsUtils
|
||||
* Don't use sleep inside the tests - active check
|
||||
* Running acceptance tests locally
|
||||
* Switch to the branch that is being tested
|
||||
* Run acceptanceTests/setup.sh
|
||||
* Run tests (make acceptance-test)
|
||||
* Example - [Tap](../acceptanceTests/tap_test.go)
|
Reference in New Issue
Block a user