From 8cca365b78e71100157bba954ffeba7e8398004d Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Tue, 16 Jun 2026 14:56:12 -0700 Subject: [PATCH] memory: correct gitea action-log API note (per-job endpoint works) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proven 2026-06-16 diagnosing arbo run #5/task 1175: the RUN-level /runs/{id}/logs 404s, but the per-JOB endpoint GET /api/v1/repos/{o}/{r}/actions/jobs/{job_id}/logs returns the full plain-text log (claude-bot basic-auth, internal :3000) — no UI needed. Also noted gitea's misleading per-step conclusions (every step shows failure once any fails; trust the log + timestamps). --- persistent-memory.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/persistent-memory.md b/persistent-memory.md index c8c272b..3b1598b 100644 --- a/persistent-memory.md +++ b/persistent-memory.md @@ -313,7 +313,7 @@ _73 older entries archived to archival-memory.md._ - `[2026-06-16]` **LiteLLM admin-UI playground can't test vLLM-backed models** — it auto-sends empty `tools:[]`, vLLM 400s (litellm #6228); the gateway `strip_empty_tools` hook is a PROXY hook and structurally can't reach the UI's in-process `litellm.completion()` call. Off-ramp = `tools/gateway-chat.html`. (Langfuse playground also out: its SSRF guard blocks internal-IP LLM connections, wontfix Langfuse #13097.) (auto-memory `reference_litellm_ui_playground_vllm_deadend`) -- `[2026-06-16]` **A gitea Actions run that "looks like it never fired" (no image, untouched build dir) usually DID fire then skipped or failed-fast.** Bit arbo TWICE: run #3 looked-never-fired but SKIPPED (change-detection `engine=0`); run #4 looked-never-fired but FAILED in ~7s (early-step). Check the run LIST + status via claude-bot (`GET /repos/{o}/{r}/actions/tasks`) BEFORE a runner-connection/dispatch theory. Gitea doesn't expose action logs via API (404 on `/runs/{id}/logs`) — read them in the UI (`/actions/runs/{id}`). +- `[2026-06-16]` **A gitea Actions run that "looks like it never fired" (no image, untouched build dir) usually DID fire then skipped or failed-fast.** Bit arbo TWICE: run #3 looked-never-fired but SKIPPED (change-detection `engine=0`); run #4 looked-never-fired but FAILED in ~7s (early-step). Check the run LIST + status via claude-bot (`GET /repos/{o}/{r}/actions/tasks`) BEFORE a runner-connection/dispatch theory. CORRECTION (2026-06-16, proven): action logs ARE readable via API at the per-JOB endpoint — `GET /api/v1/repos/{o}/{r}/actions/runs/{run}/jobs` → take a job `.id` → `GET /api/v1/repos/{o}/{r}/actions/jobs/{job_id}/logs` returns the full plain-text log (claude-bot basic-auth, internal route `10.250.50.70:3000`). Only the RUN-level `/runs/{id}/logs` 404s; the per-job one works, so no UI needed. Gotcha when reading: gitea marks **every** step `conclusion:failure` once any step fails — the per-step conclusions mislead; trust the log body + step *timestamps* (the step with real duration is the culprit) not the conclusions. (Used 2026-06-16 to diagnose arbo run #5/task 1175 = test-gate `uv run pytest` → `Failed to spawn: pytest` = pytest absent from the fresh-checkout venv sync, NOT the SSH-clone comfy-dev suspected.) - `[2026-06-16]` **vLLM 0.23.0 breaks Mistral MULTIMODAL at startup** (`MistralCommonImageProcessor has no attribute fetch_images`, #44911 regression ~0.22.1+; same class hit Mistral-3.1/