Age | Commit message (Collapse) | Author |
|
It would be preferrable to test iptables via syscall tests, but there are some
problems with that approach:
* We're limited to loopback-only, as syscall tests involve only a single
container. Other link interfaces (e.g. fdbased) should be tested.
* We'd have to shell out to call iptables anyways, as the iptables syscall
interface itself is too large and complex to work with alone.
* Running the Linux/native version of the syscall test will require root, which
is a pain to configure, is inherently unsafe, and could leave host iptables
misconfigured.
Using the go_test target allows there to be no new test runner.
PiperOrigin-RevId: 285274275
|
|
'docker exec' was getting CAP_NET_RAW even when --net-raw=false
because it was not filtered out from when copying container's
capabilities.
PiperOrigin-RevId: 272260451
|
|
We already do this for `runsc run`, but need to do the same for `runsc exec`.
PiperOrigin-RevId: 270793459
|
|
- Sandbox logs are generated when running tests
- Kokoro uploads the sandbox logs
- Supports multiple parallel runs
- Revive script to install locally built runsc with docker
PiperOrigin-RevId: 269337274
|
|
The simple test script has gotten out of control. Shard this script into
different pieces and attempt to impose order on overall test structure. This
change helps lay some of the foundations for future improvements.
* The runsc/test directories are moved into just test/.
* The runsc/test/testutil package is split into logical pieces.
* The scripts/ directory contains new top-level targets.
* Each test is now responsible for building targets it requires.
* The install functionality is moved into `runsc` itself for simplicity.
* The existing kokoro run_tests.sh file now just calls all (can be split).
After this change is merged, I will create multiple distinct workflows for
Kokoro, one for each of the scripts currently targeted by `run_tests.sh` today,
which should dramatically reduce the time-to-run for the Kokoro tests, and
provides a better foundation for further improvements to the infrastructure.
PiperOrigin-RevId: 267081397
|