From 4e8b8429f58a640e6f8875fb5f42e92fc58134f8 Mon Sep 17 00:00:00 2001 From: Chris Henzie Date: Thu, 20 Aug 2026 16:39:50 -0700 Subject: [PATCH] Document contributor workflows make test can succeed while skipping tests that require root. Explain how to enable those tests and where to find CRI test prerequisites. Add pull request expectations for documentation, testing, and CI follow-up. Assisted-by: Claude Code Signed-off-by: Chris Henzie --- BUILDING.md | 5 +++++ CONTRIBUTING.md | 15 +++++++++++++++ docs/cri/testing.md | 1 + 3 files changed, 21 insertions(+) diff --git a/BUILDING.md b/BUILDING.md index b1e9673059..ae36969890 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -261,6 +261,11 @@ During the automated CI the unit tests and integration tests are run as part of - `make integration`: run all tests, including integration tests and those which require `root`. `TESTFLAGS_PARALLEL` can be used to control parallelism. For example, `TESTFLAGS_PARALLEL=1 make integration` will lead a non-parallel execution. The default value of `TESTFLAGS_PARALLEL` is **8**. - `make cri-integration`: [CRI Integration Tests](https://github.com/containerd/containerd/blob/main/docs/cri/testing.md#cri-integration-test) run cri integration tests +A test that needs `root` calls `testutil.RequiresRoot`, which skips it unless +`-test.root` is passed. `make test` skips those tests and still succeeds, so check +whether the tests covering your change are among them. `make root-test` selects +the packages that call the helper and runs them with `-test.root`. + To execute a specific test or set of tests you can use the `go test` capabilities without using the `Makefile` targets. The following examples show how to specify a test name and also how to use the flag directly against `go test` to run root-requiring tests. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 24be9746c2..9383487e5f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -25,6 +25,21 @@ $ script/setup/install-dev-tools $ make install-deps ``` +## Pull request expectations + +- Before starting work on an issue, check whether an open pull request already + addresses it: look at the issue's linked pull requests and search open pull + requests for the issue number. +- Document features and enhancements, both at the code level and in the + user-facing docs under `docs/`. +- Test at the levels that fit the change: unit, integration, or end-to-end. + For failure injection in integration tests, use the failpoint pattern + (`internal/failpoint`, `integration/failpoint`). +- Run `make check` and the tests that cover your change locally before opening + or updating a pull request. +- Monitor your pull request's CI runs and make sure your changes are not + responsible for failures. + ## Automated and AI-generated contributions Pull requests must be opened by a human. Any use of automation to create diff --git a/docs/cri/testing.md b/docs/cri/testing.md index 27742da0ac..f9bb444317 100644 --- a/docs/cri/testing.md +++ b/docs/cri/testing.md @@ -8,6 +8,7 @@ Before sending pull requests you should at least make sure your changes have pas Follow the [building](../../BUILDING.md) instructions. ## CRI Integration Test +The tests need the host dependencies installed by `make install-deps` (see [CONTRIBUTING.md](../../CONTRIBUTING.md#setting-up-your-local-environment)). * Run all CRI integration tests: ```bash make cri-integration