TapTap/FastSync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

docs(agents): note FASTSYNC_UNDER_VALGRIND for manual valgrind runs
CI / lint (pull_request) Successful in 1m40s
Details
CI / parity-full (pull_request) Skipped
Details
CI / sanitizers (address) (pull_request) Skipped
Details
CI / sanitizers (undefined) (pull_request) Skipped
Details
CI / fuzz-build (pull_request) Skipped
Details
CI / coverage (pull_request) Skipped
Details
CI / valgrind (pull_request) Skipped
Details
CI / parity-fast (pull_request) Successful in 16s
Details
CI / build-and-test (pull_request) Successful in 51s
Details

Browse Source
This commit is contained in:
TapTap
2026-09-18 22:15:38 +02:00
parent b82aab72c5
commit 3d0672a721
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+8
View File
@@ -65,6 +65,14 @@ python3 -m pytest tests/integration/test_differential_parity.py -n 4 --dist=load
See `tests/integration/README.md` for the differential parity gate and its
`parity_caveats.py` allowlist (the residual burn-down mechanism).
Unit tests under valgrind must set `FASTSYNC_UNDER_VALGRIND=1` (CI does): the
tests use it to skip fork-based tests, because valgrind 3.22 does not expose
`vgpreload` in the guest's `/proc/self/maps`.
```bash
FASTSYNC_UNDER_VALGRIND=1 valgrind --leak-check=full --show-leak-kinds=definite --error-exitcode=1 ./build/tests
```
## CI Workflow — Waiting for Results
When running the CI workflow via `tea` (the task execution agent), always set a sufficient timeout (e.g., 600000ms) to allow CI to finish. After CI completes, check the results yourself — do not assume success. Monitor CI status via the Gitea API (see below) or `tea actions`, then inspect logs on failure.