Problem
CI's e2e lane (upstream's pr-workflow) runs every suite on gVisor and on micro-VM. A node-level arrangement a test makes must hold on both ateoms, and the two differ: the micro-VM ateom clears its checkpoint directory before writing, the gVisor ateom only creates it. #258 DeleteAfterFailedSuspend first blocked the checkpoint with an immutable file, which one lane accepted and the other did not (#256 failed the micro-VM lane on it), and was reworked to a file under the directory's name, which both refuse. Neither CONTRIBUTING.md nor FORK.md says so; CONTRIBUTING.md only names the lanes.
Proposed solution
A paragraph in CONTRIBUTING.md (the "What CI runs on a pull request" item) or a docs/dev/ page linked from it: a test's node-level arrangement runs on both ateoms; the checkpoint-directory difference and the arrangement that holds on both, as the example.
Acceptance criteria
- The note is in
CONTRIBUTING.md or a docs/dev/ page linked from it.
This issue was written by an agent.
Problem
CI's e2e lane (upstream's
pr-workflow) runs every suite on gVisor and on micro-VM. A node-level arrangement a test makes must hold on both ateoms, and the two differ: the micro-VM ateom clears its checkpoint directory before writing, the gVisor ateom only creates it. #258DeleteAfterFailedSuspendfirst blocked the checkpoint with an immutable file, which one lane accepted and the other did not (#256 failed the micro-VM lane on it), and was reworked to a file under the directory's name, which both refuse. NeitherCONTRIBUTING.mdnorFORK.mdsays so;CONTRIBUTING.mdonly names the lanes.Proposed solution
A paragraph in
CONTRIBUTING.md(the "What CI runs on a pull request" item) or adocs/dev/page linked from it: a test's node-level arrangement runs on both ateoms; the checkpoint-directory difference and the arrangement that holds on both, as the example.Acceptance criteria
CONTRIBUTING.mdor adocs/dev/page linked from it.This issue was written by an agent.