greptimedb-fuzz-ci-failure-investigation
Investigate a failed GreptimeDB fuzz CI target link by downloading GitHub Actions job logs plus fuzz artifacts such as kind logs, monitor dumps, and CSV dumps, then correlate the failure with local GreptimeDB source code. Use when the user provides a failed fuzz CI target/job URL or asks to diagnose GreptimeDB fuzz CI failures.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 6697
- Лиценз
- Apache-2.0
- Последна проверка на записа
- 21.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add GreptimeTeam/greptimedbСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
GreptimeDB Fuzz CI Failure Investigation
Investigate failed fuzz-test jobs for GreptimeTeam/greptimedb from a local
checkout. The purpose is to download the failed job's CI output and fuzz artifacts,
then explain the likely cause by correlating the evidence with GreptimeDB source.
Always pass --repo GreptimeTeam/greptimedb to gh; local remotes may point to
forks. Keep the workflow read-only: do not rerun jobs, cancel workflows, push,
comment on PRs, or delete artifacts unless the user explicitly asks.
Scope
Use this skill for fuzz CI only. In .github/workflows/integration.yml, fuzz failures
are the CI jobs that use .github/actions/fuzz-test:
fuzztest— standalone fuzz targets.unstable-fuzztest— unstable standalone fuzz target.distributed-fuzztest— distributed cluster fuzz targets.distributed-fuzztest-with-chaos— distributed fuzz targets with Chaos Mesh.
Each matrix job runs a semantic group of targets on one prepared environment.
The group defaults to fail-fast: after the first target failure it captures that
target's diagnostics and marks the remaining targets as skipped. The workflow
strategy still uses fail-fast: false, so failures do not cancel other groups.
The reusable action .github/actions/fuzz-test/action.yaml delegates each target
to .github/scripts/run-fuzz-targets.sh. CI passes FUZZ_BIN_DIR, so the script
runs the prebuilt target executable:
<prebuilt-fuzz-binary> -max_total_time=<seconds> \
-artifact_prefix=<target-dir>/libfuzzer/
Without FUZZ_BIN_DIR, such as during local reproduction, the script falls back
to cargo fuzz run <target> --fuzz-dir tests-fuzz -D -s none with the same
libFuzzer arguments.
Failed jobs upload one group artifact. Its stable name identifies the job kind, mode, and group, for example:
fuzz-distributed-remote-wal-database-and-regular-table
The artifact contains manifest.json, summary.md, and one directory per target
under targets/<target>/. A failed distributed target can include fuzz.log,
libFuzzer reproducers, CSV/SQL traces, Kind logs, monitor dumps, and Kubernetes
state. Setup failures use targets/setup/.
Inputs
The normal user input is a CI target link: a GitHub Actions job URL for one failed matrix target. Treat that URL as the primary source of truth. Example:
https://github.com/GreptimeTeam/greptimedb/actions/runs/29000666156/job/86062894741
Also accept these fallback inputs: