🛠️ Debugging CI Failures with `job-logs.txt` and the Dedicated Workflow

Development AI
1

When a CI job fails, the right approach in this repository is to debug from the raw logs first and reproduce the problem with the smallest meaningful command. This is not a blind retry loop. It is a structured, evidence-driven debugging workflow. :magnifying_glass_tilted_left:

The prompt below asks an agent to inspect job-logs.txt, identify the real root cause, use the dedicated local validation flow for the first reproduction, and keep iterating until the underlying bug is fixed. :repeat_button:

Inspect `job-logs.txt` and debug the failure using the repository's documented workflow.

Treat the raw logs as the source of truth. Identify the first real error, decide whether it is branch-related or unrelated, and reproduce it with the smallest meaningful command. If it is unrelated, report it separately instead of mixing it into the branch.

If the failure is from a local deploy, start with `APP=<role> make test-local-dedicated`. After the first repro, use `APP=<role> make test-local-rapid` for faster iteration, and switch back to `test-local-dedicated` when you need full-stack behavior.

If the failure comes from GitHub CI, work from the downloaded `job-logs.txt` or `*.log` files. If the logs show a Playwright failure, also download the matching Playwright artifacts into `/tmp/` and analyze them together with the logs.

Fix the root cause, rerun the relevant check, and keep iterating until the failure is resolved. Do not rely on screenshots alone, and do not commit log files to the repository.

What the prompt asks the agent to do

  • :page_facing_up: Read job-logs.txt and treat it as the source of truth.
  • :compass: Decide whether the failure belongs to the current branch or is unrelated.
  • :test_tube: Reproduce the issue with the smallest meaningful validation command.
  • :brick: Use the dedicated flow for the first reproduction, then switch to a faster loop for iteration.
  • :performing_arts: If the failure is a Playwright failure, download the matching artifacts and analyze them together with the logs.
  • :white_check_mark: Repeat until the actual bug is fixed and the relevant check passes.

How the debugging loop works

  1. :pushpin: Start with the raw CI log.
  2. :detective: Find the first real error, not just the final symptom.
  3. :rocket: Reproduce locally with APP=<role> make test-local-dedicated.
  4. :high_voltage: Use APP=<role> make test-local-rapid for faster follow-up iterations.
  5. :back_arrow: Switch back to dedicated when you need the fuller stack behavior.
  6. :hammer_and_wrench: Fix the root cause, rerun the relevant check, and repeat until green.

If a run is still in progress, let it finish unless you were explicitly asked to change course. :hourglass_not_done:

Why “dedicated” matters

  • :brick: The dedicated flow is the stronger single-app validation path.
  • :bullseye: It is the right choice when you need a realistic deploy reproduction and final confirmation.
  • :high_voltage: The rapid flow keeps the feedback loop short once you already know what you are changing.

Tip: when you need to rerun CI, use a targeted manual job and scope it to the affected app instead of rerunning the entire pipeline. :control_knobs: