[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Changelog entry: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• ci — workflows or build tooling

---

Description of your pull request and other information

Caps every file a test writes at 2 GiB, on every pytest and unittest step of unit-tests.yml (#1969). #1372 once wrote a 6 GB out.json per run.

• util/cap_file_size.py sets RLIMIT_FSIZE (soft and hard), restores SIGXFSZ's default action, and execs the command. Exit codes and continue-on-error are unchanged, and a breach raises File too large.
• The cap applies to test, integration, pypcap-parity (and their KTLO twins), the engine cells, unittest-ordering, project-tests and gate. project-tests drops its own ulimit -f, so the limit lives in one place.
• tests/project/test_file_size_caps_1969.py fails on any uncapped test command, and exercises the script at a small limit.
• workflows.rst gains a "File Size Caps" section.

cron-python-versions.yml's single unittest run is outside this PR's scope and stays uncapped.

Closes #1969

[JarryShaw]

GOOD TO GO at 340fd411c. A Sonnet review ran the wrapper on 3.8.20 and 3.10.21. It sets 2 GiB soft and hard limits, keeps a lower existing hard limit, raises Errno 27 for a Python writer, and kills dd with SIGXFSZ. Every unit-tests.yml job is on Ubuntu, so resource exists everywhere. setrlimit can only fail loudly, never run uncapped silently. execvp keeps exit codes and pids, so continue-on-error and coverage are unaffected. Every pytest, unittest, coverage run and run_unittest_leg command is capped, and removing the cap from any of three steps trips the pin. actionlint reports nothing new.

[JarryShaw]

NEEDS CHANGES at 340fd411c. The Python 3.15 coverage leg fails in Report coverage, though every test passed (4296 passed). The #1387 guard reports controller ['2516', '8683'], 2 xdist workers, missing data: ['8683']. main's coverage leg passes, so this PR adds a second process whose command line looks like the coverage controller. It is probably a test whose fake python now runs the real util/cap_file_size.py, which then exec's a coverage run --rcfile=.github/coverage.toml line with coverage active and no data saved. A follow-up commit will find which test it is and fix it at the root, without weakening the guard.

[JarryShaw]

GOOD TO GO at 94593673a. The Sonnet delta review confirmed that the stub fix leaves one coverage controller and preserves the recorded argv. Both regression tests fail on the old stubs. Merging is still gated on CI.

[github-actions]

Coverage: 90.07% (unit tier, Python 3.15, 94593673a, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	2	20	2	96.77%
pcapkit/const	19597	881	2618	867	92.11%
pcapkit/corekit	2505	70	792	36	96.54%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2916	164	1016	34	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17411	224	4580	189	98.10%
pcapkit/toolkit	872	177	298	8	77.18%
pcapkit/utilities	522	2	158	4	99.12%
pcapkit/vendor	4431	2341	1018	156	43.64%

Per-file detail: the coverage-html artifact of this run.