TapTap
5c8970c64f
CI / lint (pull_request) Successful in 1m29s
CI / sanitizers (address) (pull_request) Skipped
CI / sanitizers (undefined) (pull_request) Skipped
CI / fuzz-build (pull_request) Skipped
CI / coverage (pull_request) Skipped
CI / valgrind (pull_request) Skipped
CI / build-and-test (pull_request) Successful in 1m45s
The agent and skill definitions had drifted badly from the current codebase and tooling, repeating the same class of bug as the benchmark tool (references to nonexistent scripts and invented flags): - Replace the removed `python3 test.py` with the real integration command (`python3 -m pytest tests/integration/ -n 4 --dist=load -m "not setpriv"`) across agents and skills. - Fix `feature-scout`'s fabricated CLI flag list (--host, --server-mode, --use-* etc.) using the authoritative src/client/usage.c flags. - Fix `perf-analyst` benchmark flags (-m -c -> -j -z) and point at benchmark/bench.py instead of stale numbers. - Correct `code-explainer` (no getopt_long; --sendfile not -f) and version drift in the release skill (1.1.0 -> 2.20.0). - Replace GitHub/`gh` workflows with Gitea/`tea` (PRs target dev; issues via tea; branch strategy updated in all agents). - Use the built-in `-DSANITIZER=address|thread` CMake option instead of hand-rolled -fsanitize flags. - Add `-p 8080 --allow-unauthenticated` to plain-TCP server examples. - Merge the redundant security-screener into security-auditor; drop the duplicate (16 agents remain). Repo hygiene: gitignore `root/` and `test_partial_install_tmp/`, remove the empty leftover trees, delete the tracked scratch scripts tmux.sh and to_one_file.py, and note the compile_commands.json symlink in README.
128 lines
3.2 KiB
Markdown
128 lines
3.2 KiB
Markdown
---
|
|
name: pr-build
|
|
description: Builds and tests a pull request branch, fixing compilation errors and test failures. Use when the user says "build PR", "fix PR build", "run PR build", or wants to compile and test a PR branch.
|
|
---
|
|
|
|
# PR Build Skill
|
|
|
|
Builds, tests, and fixes a pull request branch. This skill CAN edit files, commit, and push.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Identify the PR branch
|
|
|
|
If the user specifies a PR number, check it out:
|
|
```bash
|
|
tea pr checkout <number>
|
|
```
|
|
|
|
If already on a PR branch, verify with:
|
|
```bash
|
|
git branch --show-current
|
|
git log dev..HEAD --oneline
|
|
```
|
|
|
|
### Step 2: Clean build
|
|
|
|
```bash
|
|
rm -rf build
|
|
cmake -B build -S . 2>&1
|
|
cmake --build build -j$(nproc) 2>&1
|
|
```
|
|
|
|
Capture both stdout and stderr.
|
|
|
|
### Step 2b: Sanitizer build (if issues suspected)
|
|
|
|
If the PR touches threading, memory management, or network code, also build with sanitizers:
|
|
|
|
```bash
|
|
# AddressSanitizer
|
|
rm -rf build-asan
|
|
cmake -B build-asan -S . -DSANITIZER=address
|
|
cmake --build build-asan -j$(nproc)
|
|
./build-asan/tests
|
|
|
|
# ThreadSanitizer (if threading changes)
|
|
rm -rf build-tsan
|
|
cmake -B build-tsan -S . -DSANITIZER=thread
|
|
cmake --build build-tsan -j$(nproc)
|
|
./build-tsan/tests
|
|
```
|
|
|
|
### Step 3: Handle build failures
|
|
|
|
If the build fails, read the error output carefully. Common issues:
|
|
|
|
**Missing include / undefined reference:**
|
|
- Check if the new `.c` file is in the right `file(GLOB ...)` directory
|
|
- Check if the new `.h` file is included properly
|
|
- Check if CMakeLists.txt needs updating (new target, new source file, new dependency)
|
|
|
|
**Type errors / implicit declarations:**
|
|
- Check function signatures match between `.h` and `.c`
|
|
- Check struct field names and types
|
|
|
|
**Linker errors:**
|
|
- Check if all required libraries are linked in CMakeLists.txt
|
|
- Check if all source files are included in the target
|
|
|
|
Use the cmake-expert agent to diagnose and fix CMake issues.
|
|
|
|
### Step 4: Run unit tests
|
|
|
|
If build succeeds:
|
|
```bash
|
|
./build/tests
|
|
```
|
|
|
|
### Step 5: Handle test failures
|
|
|
|
If tests fail:
|
|
- Read the test output carefully
|
|
- Check which test function failed and the assertion line
|
|
- Read the test source file and the module being tested
|
|
- Use the test-writer agent to investigate and fix
|
|
|
|
### Step 6: Run integration tests (optional)
|
|
|
|
```bash
|
|
python3 -m pytest tests/integration/ -n 4 --dist=load -m "not setpriv"
|
|
```
|
|
|
|
This runs the integration suite (benchmarking is `benchmark/bench.py`). It takes longer — only run if the user asks or if unit tests pass.
|
|
|
|
### Step 7: Fix and commit
|
|
|
|
If fixes were needed:
|
|
```bash
|
|
git add -A
|
|
git commit -m "Fix build: <brief description of what was fixed>"
|
|
git push
|
|
```
|
|
|
|
### Step 8: Report results
|
|
|
|
Print a summary:
|
|
|
|
```
|
|
=== PR BUILD SUMMARY ===
|
|
Branch: <branch-name>
|
|
Build: [PASS/FAIL]
|
|
Unit tests: [PASS/FAIL] (<passed>/<total>)
|
|
ASan: [CLEAN/ERRORS]
|
|
TSan: [CLEAN/ERRORS/SKIPPED]
|
|
Integration tests: [PASS/FAIL/SKIPPED]
|
|
|
|
Fixes applied: <count>
|
|
<list of fixes with commit hashes>
|
|
```
|
|
|
|
## Rules
|
|
- DO edit source files and CMakeLists.txt to fix issues
|
|
- DO commit and push fixes
|
|
- Always build from clean state (rm -rf build)
|
|
- Read error messages carefully before fixing
|
|
- Don't change functionality — only fix build/test issues
|
|
- Preserve existing code style when making fixes
|