mirror of https://github.com/k3s-io/k3s.git
Testing ADR (#9562)
* Update contributing with new links * Testing ADR Signed-off-by: Derek Nola <derek.nola@suse.com>
This commit is contained in:
parent
86f102134e
commit
57e11c72d1
|
@ -2,9 +2,9 @@
|
|||
|
||||
Thanks for taking the time to contribute to K3s!
|
||||
|
||||
Please review and follow the [Code of Conduct](https://github.com/k3s-io/k3s/blob/master/CODE_OF_CONDUCT.md).
|
||||
Please review and follow the [Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
Contributing is not limited to writing code and submitting a PR. Feel free to submit an [issue](https://github.com/k3s-io/k3s/issues/new/choose) or comment on an existing one to report a bug, provide feedback, or suggest a new feature. You can also join the discussion on [slack](https://slack.rancher.io/).
|
||||
Contributing is not limited to writing code and submitting a PR. Feel free to submit an [issue](https://github.com/k3s-io/k3s/issues/new/choose) or comment on an existing one to report a bug, provide feedback, or suggest a new feature. You can also join the discussion on [slack](https://rancher-users.slack.com/channels/k3s).
|
||||
|
||||
Of course, contributing code is more than welcome! To keep things simple, if you're fixing a small issue, you can simply submit a PR and we will pick it up. However, if you're planning to submit a bigger PR to implement a new feature or fix a relatively complex bug, please open an issue that explains the change and the motivation for it. If you're addressing a bug, please explain how to reproduce it.
|
||||
|
||||
|
@ -12,7 +12,11 @@ If you're interested in contributing documentation, please note the following:
|
|||
- Doc issues are raised in this repository, and they are tracked under the `kind/documentation` label.
|
||||
- Pull requests are submitted to the K3s documentation source in the [k3s-io docs repository.](https://github.com/k3s-io/docs).
|
||||
|
||||
If you're interested in contributing new tests, please see the `TESTING.md` in the tests directory.
|
||||
If you're interested in contributing new tests, please see the [TESTING.md](./tests/TESTING.md).
|
||||
|
||||
## Code Convetion
|
||||
|
||||
See the [code convetions documentation](./docs/contrib/code_conventions.md) for more information on how to write code for K3s.
|
||||
|
||||
### Opening PRs and organizing commits
|
||||
PRs should generally address only 1 issue at a time. If you need to fix two bugs, open two separate PRs. This will keep the scope of your pull requests smaller and allow them to be reviewed and merged more quickly.
|
||||
|
|
|
@ -0,0 +1,62 @@
|
|||
# Testing in K3s
|
||||
|
||||
Date: 2024-02-23
|
||||
|
||||
# Context
|
||||
|
||||
## Background
|
||||
|
||||
Currently, Testing in K3s is categorized into various types and spread across Github Actions and Drone CI. The types are as follows:
|
||||
|
||||
GitHub Actions:
|
||||
- Unit Tests: For testing individual components and functions, following a "white box" approach.
|
||||
- Integration Tests: Test functionalities across multiple packages, using "black box" testing.
|
||||
- Smoke Tests: Simple tests to ensure basic functionality works as expected. Broken into:
|
||||
- Cgroup: Tests cgroupv2 support.
|
||||
- Snapshotter: tests btrfs and overlayfs snapshotter support.
|
||||
- Install tests: Tests the installation of K3s on various OSes.
|
||||
|
||||
Drone CI:
|
||||
- Docker Tests: Run clusters in containers to test basic functionality. Broken into:
|
||||
- Basic Tests: Run clusters in containers to test basic functionality.
|
||||
- Sonobuoy Conformance Tests: Run clusters in containers to validate K8s conformance. Runs on multiple database backends.
|
||||
- End-to-End (E2E) Tests: Cover multi-node configuration/administration.
|
||||
|
||||
- Performance Tests: Use Terraform to test large-scale deployments of K3s clusters. These were legacy tests and are never run in CI.
|
||||
|
||||
## Problems
|
||||
|
||||
- The current testing infrastructure is complex and fragmented, leading to maintenance overhead. Not all testing is grouped inside the [tests directory](../../tests/).
|
||||
- GitHub Actions had limited resources, making it unsuitable for running larger tests.
|
||||
- GitHub Actions only supported hardware virtualiztion on Mac runners and that support was often broken.
|
||||
- Drone CI cannot handle individual testing failures. If a single test fails, the entire build is marked as failed.
|
||||
|
||||
## New Developments
|
||||
|
||||
As of late January 2024, GitHub Actions has made significant improvements:
|
||||
- The resources available to open source GitHub Actions have been doubled, with 4 CPU cores and 16GB of RAM. See blog post [here](https://github.blog/2024-01-17-github-hosted-runners-double-the-power-for-open-source/).
|
||||
- Standard (i.e. free) Linux runners now support Nested Virtualization
|
||||
|
||||
## Decision
|
||||
|
||||
We will move towards a single testing platform, GitHub Actions, and leverage the recent improvements in resources and nested virtualization support. This will involve the following changes:
|
||||
|
||||
- Test distribution based on size and complexity:
|
||||
- Unit, Integration: Will continue to run in GitHub Actions due to their smaller scale and faster execution times.
|
||||
- Install Test, Docker Basic, and E2E Tests: Will run in GitHub Actions on standard linux runners thanks to recent enhancements.
|
||||
- Docker Conformance and large E2E Tests (2+ nodes): Still utilize Drone CI for resource-intensive scenarios.
|
||||
|
||||
- Consolidating all testing-related files within the "tests" directory for better organization and clarity.
|
||||
- Cgroup smoke tests will be removed. As multiple Operating Systems now support CgroupV2 by default, these tests are no longer relevant.
|
||||
- Snapshotter smoke test will be converted into a full E2E test.
|
||||
- Remove of old performance tests, as they are no longer relevant. Scale testing is already handled by QA as needed.
|
||||
|
||||
Tracking these changes is with [this issue](https://github.com/k3s-io/k3s/issues/9477)
|
||||
|
||||
## Consequences
|
||||
|
||||
- The testing infrastructure will be more organized and easier to maintain.
|
||||
- The move to GitHub Actions will allow for faster feedback on PRs and issues.
|
||||
- The removal of old tests will reduce the maintenance overhead.
|
||||
- New testing process can be used as a model for related projects.
|
||||
|
Loading…
Reference in New Issue