diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 594ea4b33..0e996c493 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,66 +1,3 @@ # CONTRIBUTING Guide -## About KubeVela - -KubeVela project is initialized and maintained by the cloud native community since day 0 with [bootstrapping contributors from 8+ different organizations](https://github.com/kubevela/kubevela/graphs/contributors). -We intend for KubeVela to have an open governance since the very beginning and donate the project to neutral foundation as soon as it's released. -To help us create a safe and positive community experience for all, we require all participants to adhere to the [Code of Conduct](./CODE_OF_CONDUCT.md). - -This document is a guide to help you through the process of contributing to KubeVela. - -## Become a contributor - -You can contribute to KubeVela in several ways. Here are some examples: - -* Contribute to the KubeVela codebase. -* Contribute to the [KubeVela docs](https://github.com/kubevela/kubevela.io). -* Report and triage bugs. -* Develop community CRD operators as workload or trait and contribute to [catalog](https://github.com/oam-dev/catalog). -* Write technical documentation and blog posts, for users and contributors. -* Organize meetups and user groups in your local area. -* Help others by answering questions about KubeVela. - -For more ways to contribute, check out the [Open Source Guides](https://opensource.guide/how-to-contribute/). - - -### Report bugs - -Before submitting a new issue, try to make sure someone hasn't already reported the problem. -Look through the [existing issues](https://github.com/kubevela/kubevela/issues) for similar issues. - -Report a bug by submitting a [bug report](https://github.com/kubevela/kubevela/issues/new?assignees=&labels=kind%2Fbug&template=bug_report.md&title=). -Make sure that you provide as much information as possible on how to reproduce the bug. - -Follow the issue template and add additional information that will help us replicate the problem. - -#### Security issues - -If you believe you've found a security vulnerability, please read our [security policy](https://github.com/kubevela/kubevela/blob/master/SECURITY.md) for more details. - -### Suggest enhancements - -If you have an idea to improve KubeVela, submit an [feature request](https://github.com/kubevela/kubevela/issues/new?assignees=&labels=kind%2Ffeature&template=feature_request.md&title=%5BFeature%5D). - -### Triage issues - -If you don't have the knowledge or time to code, consider helping with _issue triage_. The community will thank you for saving them time by spending some of yours. - -Read more about the ways you can [Triage issues](/contribute/triage-issues.md). - -### Answering questions - -If you have a question and you can't find the answer in the [documentation](https://kubevela.io/docs/), -the next step is to ask it on the [github discussion](https://github.com/kubevela/kubevela/discussions). - -It's important to us to help these users, and we'd love your help. You can help other KubeVela users by answering [their questions](https://github.com/kubevela/kubevela/discussions). - -### Your first contribution - -Unsure where to begin contributing to KubeVela? Start by browsing issues labeled `good first issue` or `help wanted`. - -- [Good first issue](https://github.com/kubevela/kubevela/labels/good%20first%20issue) issues are generally straightforward to complete. -- [Help wanted](https://github.com/kubevela/kubevela/labels/help%20wanted) issues are problems we would like the community to help us with regardless of complexity. - -If you're looking to make a code change, see how to set up your environment for [local development](contribute/developer-guide.md). - -When you're ready to contribute, it's time to [Create a pull request](/contribute/create-pull-request.md). +Please refer to https://kubevela.io/docs/contributor/overview for details. diff --git a/contribute/README.md b/contribute/README.md index ad567c9fc..9103e9241 100644 --- a/contribute/README.md +++ b/contribute/README.md @@ -1,9 +1,3 @@ # Contribute -This directory contains guides for contributors to the KubeVela project. - -* [Create a pull request](./create-pull-request.md) -* [Developer guide](./developer-guide.md) -* [Triage issues](./triage-issues.md) -* [Code conventions](./coding-conventions.md) -* [Develop Code Flow](./develop-code-flow.pdf) +Please refer to https://kubevela.io/docs/contributor/overview for details. diff --git a/contribute/coding-conventions.md b/contribute/coding-conventions.md index ee94c2a30..01c5857b0 100644 --- a/contribute/coding-conventions.md +++ b/contribute/coding-conventions.md @@ -1,166 +1,3 @@ # KubeVela code conventions -- Bash - - - https://google.github.io/styleguide/shell.xml - - - Ensure that build, release, test, and cluster-management scripts run on - macOS - -- Go - - - [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) - - - [Effective Go](https://golang.org/doc/effective_go.html) - - - Know and avoid [Go landmines](https://gist.github.com/lavalamp/4bd23295a9f32706a48f) - - - Comment your code. - - [Go's commenting conventions](http://blog.golang.org/godoc-documenting-go-code) - - If reviewers ask questions about why the code is the way it is, that's a - sign that comments might be helpful. - - - Command-line flags should use dashes, not underscores - - - API - - According to RFC3986, URLs are "case sensitive". KubeVela uses snake_case for API URLs. - - e.g.: `POST /v1/cloud_clusters` - - - Naming - - Please consider package name when selecting an interface name, and avoid - redundancy. - - - e.g.: `storage.Interface` is better than `storage.StorageInterface`. - - - Do not use uppercase characters, underscores, or dashes in package - names. - - Please consider parent directory name when choosing a package name. - - - so pkg/controllers/autoscaler/foo.go should say `package autoscaler` - not `package autoscalercontroller`. - - Unless there's a good reason, the `package foo` line should match - the name of the directory in which the .go file exists. - - Importers can use a different name if they need to disambiguate. - - - Locks should be called `lock` and should never be embedded (always `lock - sync.Mutex`). When multiple locks are present, give each lock a distinct name - following Go conventions - `stateLock`, `mapLock` etc. - -- KubeVela also follows the Kubernetes conventions - - - [API changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) - - - [API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) - -## Testing conventions - -- All new packages and most new significant functionality must come with unit - tests - -- Table-driven tests are preferred for testing multiple scenarios/inputs; for - example, see [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go) - -- Unit tests must pass on macOS and Windows platforms - if you use Linux - specific features, your test case must either be skipped on windows or compiled - out (skipped is better when running Linux specific commands, compiled out is - required when your code does not compile on Windows). - -- Avoid relying on Docker hub (e.g. pull from Docker hub). Use gcr.io instead. - -- Avoid waiting for a short amount of time (or without waiting) and expect an - asynchronous thing to happen (e.g. wait for 1 seconds and expect a Pod to be - running). Wait and retry instead. - -- Significant features should come with integration (test/integration) and/or - end-to-end (e2e/) tests. TOOD(@wonderflow): add detail test guides. - - Including new vela cli commands and major features of existing commands - - -## Directory and file conventions - -- Avoid package sprawl. Find an appropriate subdirectory for new packages. - - Libraries with no more appropriate home belong in new package - subdirectories of pkg/util - -- Avoid general utility packages. Packages called "util" are suspect. Instead, - derive a name that describes your desired function. For example, the utility - functions dealing with waiting for operations are in the "wait" package and - include functionality like Poll. So the full name is wait.Poll - -- All filenames should be lowercase - -- Go source files and directories use underscores, not dashes - - Package directories should generally avoid using separators as much as - possible (when packages are multiple words, they usually should be in nested - subdirectories). - -- Document directories and filenames should use dashes rather than underscores - -- Contrived examples that illustrate system features belong in - /docs/user-guide or /docs/admin, depending on whether it is a feature primarily - intended for users that deploy applications or cluster administrators, - respectively. Actual application examples belong in /examples. - - Examples should also illustrate [best practices for configuration and using the system](https://kubernetes.io/docs/concepts/configuration/overview/) - -- Third-party code - - - Go code for normal third-party dependencies is managed using - [go modules](https://github.com/golang/go/wiki/Modules) - - - Other third-party code belongs in `/third_party` - - forked third party Go code goes in `/third_party/forked` - - forked _golang stdlib_ code goes in `/third_party/forked/golang` - - - Third-party code must include licenses - - - This includes modified third-party code and excerpts, as well - -## Logging Conventions - -### Structured logging - -We recommend using `klog.InfoS` to structure the log. The `msg` argument need start from a capital letter. -and name arguments should always use lowerCamelCase. - -```golang -// func InfoS(msg string, keysAndValues ...interface{}) -klog.InfoS("Reconcile traitDefinition", "traitDefinition", klog.KRef(req.Namespace, req.Name)) -// output: -// I0605 10:10:57.308074 22276 traitdefinition_controller.go:59] "Reconcile traitDefinition" traitDefinition="vela-system/expose" -``` - -### Use `klog.KObj` and `klog.KRef` for Kubernetes objects - -`klog.KObj` and `klog.KRef` can unify the output of kubernetes object. - -```golang -// KObj is used to create ObjectRef when logging information about Kubernetes objects -klog.InfoS("Start to reconcile", "appDeployment", klog.KObj(appDeployment)) -// KRef is used to create ObjectRef when logging information about Kubernetes objects without access to metav1.Object -klog.InfoS("Reconcile application", "application", klog.KRef(req.Namespace, req.Name)) -``` - -### Logging Level - -[This file](https://github.com/kubevela/kubevela/blob/master/pkg/controller/common/logs.go) contains KubeVela's log level, -you can set the log level by `klog.V(level)`. - -```golang -// you can use klog.V(common.LogDebug) to print debug log -klog.V(common.LogDebug).InfoS("Successfully applied components", "workloads", len(workloads)) -``` - -Looking for more details in [Structured Logging Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md#structured-logging-in-kubernetes). - - -## Linting and formatting - -To ensure consistency across the Go codebase, we require all code to pass a number of linter checks. - -To run all linters, use the `reviewable` Makefile target: - -```shell script -make reviewable -``` - -The command will clean code along with some lint checks. Please remember to check in all changes after that. \ No newline at end of file +Please refer to https://kubevela.io/docs/contributor/code-conventions for details. \ No newline at end of file diff --git a/contribute/create-pull-request.md b/contribute/create-pull-request.md index 92471203e..affb085b6 100644 --- a/contribute/create-pull-request.md +++ b/contribute/create-pull-request.md @@ -1,149 +1,3 @@ # Create a pull request -We're excited that you're considering making a contribution to the KubeVela project! -This document guides you through the process of creating a [pull request](https://help.github.com/en/articles/about-pull-requests/). - -## Before you begin - -We know you're excited to create your first pull request. Before we get started, read these resources first: - -- Learn how to start [Contributing to KubeVela](/CONTRIBUTING.md). -- Make sure your code follows the relevant [style guides](/contribute/style-guides). - -## Your first pull request - -If this is your first time contributing to an open-source project on GitHub, make sure you read about [Creating a pull request](https://help.github.com/en/articles/creating-a-pull-request). - -To increase the chance of having your pull request accepted, make sure your pull request follows these guidelines: - -- Title and description matches the implementation. -- Commits within the pull request follow the [Formatting guidelines](#Formatting-guidelines). -- The pull request closes one related issue. -- The pull request contains necessary tests that verify the intended behavior. -- If your pull request has conflicts, rebase your branch onto the main branch. - -If the pull request fixes a bug: - -- The pull request description must include `Closes #` or `Fixes #`. -- To avoid regressions, the pull request should include tests that replicate the fixed bug. - -Please refer to the [code conventions](/contribute/coding-conventions.md) for better code style and conventions. - -## Code review - -Once you've created a pull request, the next step is to have someone review your change. -A review is a learning opportunity for both the reviewer and the author of the pull request. - -If you think a specific person needs to review your pull request, then you can tag them in the description or in a comment. -Tag a user by typing the `@` symbol followed by their GitHub username. - -We recommend that you read [How to do a code review](https://google.github.io/eng-practices/review/reviewer/) to learn more about code reviews. - -## Formatting guidelines - -A well-written pull request minimizes the time to get your change accepted. -These guidelines help you write good commit messages and descriptions for your pull requests. - -### Commit message format - -KubeVela follows the [conventional-commits](https://www.conventionalcommits.org/en/v1.0.0/) and [commit messages best practices](https://chris.beams.io/posts/git-commit/) to improve better history information. - -The commit message should be structured as follows: - -``` -[optional scope]: - -[optional body] -``` - -#### Examples: - -Commit message with scope: - -``` -Feat(lang): add polish language -``` - -Commit message with no body: - -``` -Docs: correct spelling of CHANGELOG -``` - -Commit message with multi-paragraph body: - -``` -Fix: correct minor typos in code - -see the issue for details - -on typos fixed. - -Reviewed-by: Z -Refs #133 -``` - -#### `` (required) - -Type is required to better capture the area of the commit, based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). - -We capitalize the `` to make sure the subject line is capitalized. `` can be one of the following: - -* **Feat**: A new feature -* **Fix**: A bug fix -* **Docs**: Documentation only changes -* **Build**: Changes that affect the build system or external dependencies -* **Style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) -* **Refactor**: A code change that neither fixes a bug nor adds a feature -* **Perf**: A code change that improves performance -* **Test**: Adding missing or correcting existing tests -* **Chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation - -#### `` (optional) - -Scope is optional, it may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, it is could be anything specifying place of the commit change. Github issue link is -also a valid scope. For example: Fix(cli), Feat(api), Fix(#233), etc. - -You can use `*` when the change affects more than a single scope. - -#### `` (required) - -The subject MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., "Fix: array parsing issue when multiple spaces were contained in string", instead of "Fix: bug". - -#### `` (optional) - -A longer commit body may be provided after the short subject, providing additional contextual information about the code changes. The body MUST begin one blank line after the description. - -#### Area - -The area should use upper camel case, e.g. UpperCamelCase. - -Prefer using one of the following areas: - -- **Application:** Changes to the application controller. -- **Component:** Changes to the component related code or definition controller. -- **Trait:** Changes to the trait related code or definition controller. -- **CUE:** Changes to the CUE related logic. -- **Docs:** Changes to documentation. -- **AppConfig:** Changes to AppConfig related code. - -**Examples** - -- `Application: Support workflow in application controller` -- `CUE: Fix patch parse issues` -- `Docs: Changed url to URL in all documentation files` - -### Pull request titles - -The KubeVela team _squashes_ all commits into one when we accept a pull request. -The title of the pull request becomes the subject line of the squashed commit message. -We still encourage contributors to write informative commit messages, as they become a part of the Git commit body. - -We use the pull request title when we generate change logs for releases. As such, we strive to make the title as informative as possible. - -Make sure that the title for your pull request uses the same format as the subject line in the commit message. If the format is not followed, we will add a label `title-needs-formatting` on the pull request. - -### Pass all the CI checks - -Before merge, All test CI should pass green. -The `codecov/project` should also pass. This means the coverage should not drop. See [Codecov commit status](https://docs.codecov.io/docs/commit-status#project-status). +Please refer to https://kubevela.io/docs/contributor/code-contribute#create-a-pull-request for details. \ No newline at end of file diff --git a/contribute/developer-guide.md b/contribute/developer-guide.md index ec192577b..8814d274c 100644 --- a/contribute/developer-guide.md +++ b/contribute/developer-guide.md @@ -1,193 +1,3 @@ # Developer guide -This guide helps you get started developing KubeVela. - -## Prerequisites - -1. Golang version 1.17+ -2. Kubernetes version v1.20+ with `~/.kube/config` configured. -3. ginkgo 1.14.0+ (just for [E2E test](./developer-guide.md#e2e-test)) -4. golangci-lint 1.38.0+, it will install automatically if you run `make`, you can [install it manually](https://golangci-lint.run/usage/install/#local-installation) if the installation is too slow. -5. kubebuilder v3.1.0+ and you need to manually install the dependency tools for unit test. -6. [CUE binary](https://github.com/cue-lang/cue/releases) v0.3.0+ - -
- Install Kubebuilder manually - -linux: - -``` -wget https://storage.googleapis.com/kubebuilder-tools/kubebuilder-tools-1.21.2-linux-amd64.tar.gz -tar -zxvf kubebuilder-tools-1.21.2-linux-amd64.tar.gz -mkdir -p /usr/local/kubebuilder/bin -sudo mv kubebuilder/bin/* /usr/local/kubebuilder/bin -``` - -macOS: - -``` -wget https://storage.googleapis.com/kubebuilder-tools/kubebuilder-tools-1.21.2-darwin-amd64.tar.gz -tar -zxvf kubebuilder-tools-1.21.2-darwin-amd64.tar.gz -mkdir -p /usr/local/kubebuilder/bin -sudo mv kubebuilder/bin/* /usr/local/kubebuilder/bin -``` - -For other OS or system architecture, please refer to https://storage.googleapis.com/kubebuilder-tools/ - -
- -You may also be interested with KubeVela's [design](https://github.com/oam-dev/kubevela/tree/master/design/vela-core) before diving into its code. - -## Build - -- Clone this project - -```shell script -git clone git@github.com:oam-dev/kubevela.git -``` - -KubeVela includes two parts, `vela core` and `vela cli`. - -- The `vela core` is actually a K8s controller, it will watch OAM Spec CRD and deploy resources. -- The `vela cli` is a command line tool that can build, run apps(with the help of `vela core`). - -For local development, we probably need to build both of them. - -- Build Vela CLI - -```shell script -make -``` - -After the vela cli built successfully, `make` command will create `vela` binary to `bin/` under the project. - -- Configure `vela` binary to System PATH - -```shell script -export PATH=$PATH:/your/path/to/project/kubevela/bin -``` - -Then you can use `vela` command directly. - -- Build Vela Core - -```shell script -make manager -``` - -- Run Vela Core - -Firstly make sure your cluster has CRDs, below is the command that can help install all CRDs. - -```shell script -make core-install -``` - -To ensure you have created vela-system namespace and install definitions of necessary module. -you can run the command: - -```shell script -make def-install -``` - -And then run locally: - -```shell script -make core-run -``` - -This command will run controller locally, it will use your local KubeConfig which means you need to have a k8s cluster -locally. If you don't have a one, we suggest that you could setup up a cluster with [kind](https://kind.sigs.k8s.io/). - -When you're developing `vela-core`, make sure the controller installed by helm chart is not running. -Otherwise, it will conflict with your local running controller. - -You can check and uninstall it by using helm. - -```shell script -helm list -A -helm uninstall -n vela-system kubevela -``` - -## Use - -You can try use your local built binaries follow [the documentation](https://kubevela.io/docs/quick-start). - -## Testing - -### Unit test - -```shell script -make test -``` - -To execute the unit test of the API module, the mongodb service needs to exist locally. - -```shell script -make unit-test-apiserver -``` - -### E2E test - -**Before e2e test start, make sure you have vela-core running.** - -```shell script -make core-run -``` - -Start to test. - -```shell script -make e2e-test -``` - -## Contribute apiserver and [velaux](https://github.com/oam-dev/velaux) - -Before start, please make sure you have already started the vela controller environment. - -```shell -make run-apiserver -``` - -By default, the apiserver will serving at "0.0.0.0:8000". - -Get the velaux code by: - -```shell -git clone git@github.com:oam-dev/velaux.git -``` - -Configure the apiserver address: - -```shell -cd velaux -echo "BASE_DOMAIN='http://127.0.0.1:8000'" > .env -``` - -Make sure you have installed [yarn](https://classic.yarnpkg.com/en/docs/install). - -```shell -yarn install -yarn start -``` - -To execute the e2e test of the API module, the mongodb service needs to exist locally. - -```shell script -# save your config -mv ~/.kube/config ~/.kube/config.save - -kind create cluster --image kindest/node:v1.20.7@sha256:688fba5ce6b825be62a7c7fe1415b35da2bdfbb5a69227c499ea4cc0008661ca --name worker -kind get kubeconfig --name worker --internal > /tmp/worker.kubeconfig -kind get kubeconfig --name worker > /tmp/worker.client.kubeconfig - -# restore your config -mv ~/.kube/config.save ~/.kube/config - -make e2e-apiserver-test -``` - -## Next steps - -- Read our [code conventions](coding-conventions.md) -- Learn how to [Create a pull request](create-pull-request.md) +Please refer to https://kubevela.io/docs/contributor/code-contribute for details. \ No newline at end of file diff --git a/contribute/testcode-guidance.md b/contribute/testcode-guidance.md index 504513ade..41876594c 100644 --- a/contribute/testcode-guidance.md +++ b/contribute/testcode-guidance.md @@ -1,91 +1,4 @@ -# Defination of concept -Generally, there are three types of test cases: - -- unit test； -- integration test , with mocking test； -- e2e test - -each of them brings us different gains and pains. we will discuss each of them. -## Unit Test -The main purposes of writing and maintaining unit tests are as follows: - -- Explicit: ensure that the function behavior meets the design expectations. -- Implicit: facilitates more reasonable code structure and interface-oriented programming. - -Test target of a unit test is a class or a segment of algorithm code. In theory, functions with relatively independent logic should has at least one unit test case, and new public functions must too (except for getter and setter). - -Basic principles for writing a single test are: - -- Keep It Simple and Stupid -- One case covers only one scenario. -- Complex mock tools are powerful, such as golang/mock, are not recommended. When you think you have to introduce mocking to unit test, what you really need is Integration test or event e2e test。 - -Single test requires high efficiency. For example, during code refactoring, after a function logic is modified, unittest of the entire module may be triggered to ensure that the modification meets expectations. - -## Integration Test -The propose of integration test is to setup parts of highly associated modules in a system, test is the interaction between these modules meets expectations. In kubernetes product or distribution tests, it is mainly divided into two categories: +# Principle of Test -- The master component which contains : apiserver、 controllers、webooks, and schedulers. You need to add corresponding tests to major processes such as scale-out, release, and scheduling. With the mock sigmalet capability, you need to add a test coverage that includes the Automated Logic after the sigmalet exception. -- slave component, including the kubelet、cri implementations、daemonsets. you can add corresponding tests like creating, destroying, and restarting a pod or a crd. - -The master level integration test does not care how pods are created on the node. Therefore, it can mock node level behavior to speed up the test efficiency. -The slave level integration test does not care how pods are scheduled, and therefore doesn't need to setup master component. - -## E2E Test -The propose of e2e test is to simulate The user's real behavior, suitable for verification of the whole product. - -we recommend e2e test to be added in the following situations: - -- To interact with upstream and downstream products, for example: - 1. Some kubelet tests need to verify the attributes of the final allocated container from the docker level. - 1. Some controller test needs to interact with a service outside of the cluster, like a cloud service. -- Core feature: each core feature must has at least one e2e test. - -# Best Practice -The purpose of the test is to ensure the quality of continuous software delivery, with emphasis on the word "continuous". It is necessary to ensure not only the quality of the current delivery, but also the quality of future software delivery. It is particularly important to make good use of the respective advantages of the three types of tests and combine them to ensure the overall quality of the software. - -| | Time consumed Running | Test Stability | Can simulate User behavior | -| --- | --- | --- | --- | -| unittest | minimal | high | no | -| integration test | middium | middium | almost | -| e2e test | much | low | yes | - - - -Time consumed Running is easy to understand here. A larger scale of software ability a test is covering, the more time environment preparation and case running will consume us, therefore the testing efficiency is also lower. -In terms of stability, the larger the case coverage scale is, the more problems it may encounter, and some of the probelems are not the real bugs we want to discover, but merely noises. In simulating real user behavior, only e2e can cover end-to-end to ensure that the entire link can work together. -​ - -As for the long-term value, it refers to the value of the existing case in the continuous software iteration process. For unittest, during code refactoring, it is adjusted with the adjustment of class and funciton, the code base is consistent with the hot spots in software iteration and continues to evolve. -​ - -However, integration/e2e test is usually split into subsystem boundaries, whose external interfaces are relatively stable (there are very few functional changes during the software iteration of distributed systems, generally forward compatibility),integration/e2e test code base is relatively stable, which is very important in the future evolution of the system. It can timely discover whether new functions damage existing functions. -​ - -Combined with the characteristics of all three, the best way to balance is to comply with the pyramid model. The chassis is unittest, the middle is integration test, and the top layer is e2e. -​ - -``` - \ - / \ - / \ - / \ - / e2e \ - /---------- - / \ - /intergeration\ - / \ - /-----------------\ - / \ - / unit-test \ - / \ ---------------------------- -``` - -KubeVela would like to follow the 70/20/10 principle. that is, 70% unittest,20% integration test, and 10% e2e test. Each module has some differences. However, the higher the upper layer, the larger the test coverage, but the smaller the test case set. This pyramid model remains unchanged. The following situations need to be avoided: -​ - - -- Inverted pyramid, all rely on e2e to build the test -- Funnel model, a large number of unit + e2e test, but no integration test +Please refer to https://kubevela.io/docs/contributor/principle-of-test for details. \ No newline at end of file diff --git a/contribute/triage-issues.md b/contribute/triage-issues.md index 87a8a50d2..5409b31ff 100644 --- a/contribute/triage-issues.md +++ b/contribute/triage-issues.md @@ -1,40 +1,3 @@ # Triage issues -Triage helps ensure that issues resolve quickly by: - -- Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for - an issue to explain how an end user experiences a problem and what actions they took. -- Giving a contributor the information they need before they commit to resolving an issue. -- Lowering the issue count by preventing duplicate issues. -- Streamlining the development process by preventing duplicate discussions. - -This document gives you some ideas on what you can do to help. For more information, read more about [how the core KubeVela team triage issues](/ISSUE_TRIAGE.md). - -## Improve issues - -Improve issues by suggesting improvements to the title and description. If you think an issue has formatting issues, -bad language, or grammatical errors, post a comment to let the author and maintainers know. - -## Report resolved issues - -If you think an issue has been resolved, or is no longer relevant, suggest us to close it. -Add a comment on the issue, where you explain the reason it should be closed. -Make sure to include any related issues and pull requests. - -## Investigate issues - -Investigate issues that we haven't been able to reproduce yet. -In some cases, there are many combinations of usage that make it difficult for us to reproduce certain issues. -Help us by adding more information. - -## Vote on issues - -Use [GitHub reactions](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments) -to let us know what's important to you. Vote on bugs if you've experienced the same problem. **Don't vote, or react, by commenting on the issue.** - -Read more about [how we prioritize issues](/ISSUE_TRIAGE.md#4-prioritization-of-issues). - -## Report duplicates - -If you find two issues that describe the same thing, add a comment in one of the issues, with a reference (`#`) to the other. -Explain why you think the issue is duplicated. +Please refer to https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md for details. \ No newline at end of file