ci: failed E2E jobs keep the k3s log and node description
Summary
Since #390 moved k3s into a container, 3 of 49 E2E jobs timed out in "Finalize k3s" because the node never reported Ready within 120 s. The latest were two jobs in one main run, 39175060996. In the other jobs the step takes 0.7 to 11 s. None of the failed jobs kept anything from k3s, so there is no way to tell why the node stayed NotReady, and main goes red until someone reruns it.
Changes
Both E2E jobs' failure steps now also save docker logs k3s as k3s.log and kubectl describe nodes as k8s-nodes.log in the uploaded logs. kubectl reads the kubeconfig that "Finalize k3s" copies before its wait, so the node description works even when that wait is what failed. cicd.md lists the new files.
Type of Change
- Bug fix (non-breaking change that fixes an issue)
- New feature (non-breaking change that adds functionality)
- Breaking change (fix or feature that would cause existing functionality to change)
- Documentation update
- Refactoring (no functional changes)
- CI/CD or tooling changes
Test Plan
- Backend unit tests pass (
cd backend && uv run pytest tests/unit) - Frontend unit tests pass (
cd frontend && npm run test) - Backend E2E tests pass (
docker compose exec -T backend sh -c 'uv sync --group test --no-dev --frozen --no-install-project --no-build && pytest tests/e2e') - Frontend E2E tests pass (
cd frontend && npm run test:e2e) - API spec and client regenerated if routes or schemas changed (
./deploy.sh openapi, then./deploy.sh types), never edited by hand - Manual testing performed
Validation: actionlint passes, and both commands ran against a local k3s container (the node's conditions and 10720 log lines). The steps only run on failure, so this PR's green run won't exercise them.
Checklist
- My code follows the project's style guidelines
- I have run
pre-commit run --all-filesand all checks pass - I have added tests that prove my fix/feature works
- I have updated documentation if needed
- My changes don't introduce new warnings
Summary by cubic
Failed E2E jobs now keep the k3s container log and node description, so timeouts in "Finalize k3s" can be diagnosed instead of rerunning blind.
Both E2E jobs' failure steps now also run docker logs k3s and kubectl describe nodes, uploading them as k3s.log and k8s-nodes.log with the existing logs. kubectl reads the kubeconfig that "Finalize k3s" copies before its wait, so the node description works even when that wait is what failed. docs/operations/cicd.md lists the new files.