Claude instructions to reproduce/troubleshoot CI failures#3778
Claude instructions to reproduce/troubleshoot CI failures#3778cataphract wants to merge 5 commits intomasterfrom
Conversation
25f80d4 to
b057948
Compare
|
✨ Fix all issues with BitsAI or with Cursor
|
.claude/ci/build-slim-package.py
Outdated
| @@ -0,0 +1,305 @@ | |||
| #!/usr/bin/env -S uv run --script | |||
There was a problem hiding this comment.
This is essentially doing the same than tooling/bin/build-debug-artifact?
Only that it seemingly doesn't take care of caching the build, i.e. full rebuild every time? - I see, dockerh does that. Odd.
There was a problem hiding this comment.
I just looked at it, and if we want to use tooling/bin/build-debug-artifactinstead, it needs to be updated to use the centos build. Because otherwise the bookworm images are too recent for system-tests
There was a problem hiding this comment.
Well, I've been using tooling/bin/build-debug-artifact all the time successfully for system tests. Did you actually try it? (./tooling/bin/build-debug-artifact gnu-aarch64-8.2-nts /Users/bob.weinand/system-tests/binaries is what I've been using mostly)
There was a problem hiding this comment.
I'll try, but the images for apache-mod-... are the appsec-ci images, which are based on bullseye
There was a problem hiding this comment.
yeah, fails:
[08-Apr-2026 15:02:37 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'ddtrace.so'
(tried: .../ddtrace.so (/lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
(required by .../ddtrace.so)), ...
There was a problem hiding this comment.
I wasn't aware that we were using different base images for system tests :-(
There was a problem hiding this comment.
I see, I was working with php-fpm-* images.
There was a problem hiding this comment.
We really ought to unify images between appsec and tracer. (Ideally by just putting everything missing into bookworm images)
There was a problem hiding this comment.
I've changed it to build on centos, like on ci.
.claude/ci/system-tests.md
Outdated
| variant. Empty stub files satisfy this for versions you don't build. | ||
| Profiling can also be fully stubbed. See | ||
| [section 1c](#1c-slim-build--one-php-version-only) for all stub | ||
| commands. |
There was a problem hiding this comment.
Why is this talking about generate-final-atrifact at all? seems like noise, you always want a local build?
There was a problem hiding this comment.
Yeah, this has leftovers from a previous strategy. I'll clean that up
.claude/ci/download-artifacts
Outdated
| @@ -0,0 +1,390 @@ | |||
| #!/usr/bin/env -S uv run --script | |||
There was a problem hiding this comment.
Two questions:
a) Can we move this under tooling/bin ?
b) Would it be reasonable to have it as PHP script instead of python?
| Output: `target/debug/libdatadog_php_profiling.so` (~144 MB vs ~20 MB for profiler-release). | ||
| Use the same `php -d extension=...` command, just point to the debug path. | ||
|
|
||
| ## ZTS tests -- parallel PECL extension |
There was a problem hiding this comment.
There was a problem hiding this comment.
yeah, once it moved to use the ci bookworm images this no longer became necessary. I'll reword.
| ``` | ||
| logs/docker/weblog/logs/php_error.log | ||
| logs/docker/weblog/logs/tracer.log | ||
| ``` |
There was a problem hiding this comment.
Something I noticed is that it sometimes adds debug info, and then becomes frustrated because it doesn't show up.
fprintf(stderr), php_log_err(E_NOTICE) etc.
Basically, it has the tracer logs, so it should simply use LOG(ERROR, <printf compatible args>) in tracer code or error!() in profiler code, and it'll definitely show up.
There was a problem hiding this comment.
I've tested this and added a section explainging debug methods. Interestinglt, error! doesn't print anything either with the current config in system-tests.
- Move download-artifacts from .claude/ci/ to tooling/bin/ and update all references in documentation. - Rewrite download-artifacts into PHP and use curl multi handles. Time to find the datadog-setup.php from a commit drops from ~35 s to ~10 s. - Delete build-slim-package.py; its functionality is now more or less covered by build-debug-artifact, the difference being in that build-debug-artifacts builds, well, debug artifacts, unlike CI. - Switch build-debug-artifact from bookworm to centos-7 images for GLIBC 2.17 compatibility with all weblog base images. - Use debug build profiles (CFLAGS=-O0, cargo dev profile, cmake Debug) instead of release/RelWithDebInfo. - Add Rust appsec helper build support to build-debug-artifact. - Resolve libddwaf commit on the host to avoid git failures in worktrees; pass LIBDDWAF_GIT_COMMIT to cmake in build-appsec-helper.sh. - Suppress git safe.directory errors in build-appsec-helper-rust.sh. - Simplify system-tests.md: remove stub file instructions, point to "Slim package with debug binaries" section in building-locally.md. - Simplify github-actions-profiler.md: note that bookworm images already include the parallel PECL extension. - Add "Slim package with debug binaries" section to building-locally.md documenting build-debug-artifact usage.
ef7269e to
ad04b9f
Compare
.claude/ci/windows-tests.md
Outdated
| Matrix: PHP 7.2--8.5 (versions where `version_compare($v, "7.2", ">=")`) | ||
|
|
||
| ## What It Tests | ||
|
|
||
| `windows test_c` starts `httpbin-windows` and `php-request-replayer-2.0-windows` |
There was a problem hiding this comment.
Can we try avoiding info which becomes trivially stale, e.g. say Matrix: PHP 7.2+, php-request-replayer-*-windows etc.? (also in the other files)
Benchmarks [ tracer ]Benchmark execution time: 2026-04-09 14:38:49 Comparing candidate commit 8d0cfcd in PR branch Found 5 performance improvements and 3 performance regressions! Performance is the same for 186 metrics, 0 unstable metrics. scenario:ContextPropagationBench/benchInject64Bit-opcache
scenario:EmptyFileBench/benchEmptyFileOverhead
scenario:MessagePackSerializationBench/benchMessagePackSerialization
scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache
scenario:PDOBench/benchPDOOverhead
scenario:PDOBench/benchPDOOverheadWithDBM
scenario:PHPRedisBench/benchRedisOverhead
scenario:SamplingRuleMatchingBench/benchRegexMatching4-opcache
|
Description
Add instructions so that claude can monitor CI pipelines, download artifacts, reproduce and troubleshoot CI failures locally.
These were mostly generated through several iterations where claude is asked to execute jobs by reading the instructions and suggest changes to the files and then by manually reviewing the suggestions.
In the end, the instructions don't need to be 100% accurate, and claude fails to closely follow the instructions 100% of the time anyway; the point is that the instructions and the helper scripts allow it to mimic the CI jobs locally in a reasonable amount of time, without excessive trial and error.
Reviewer checklist