[eyevinn-developer]

Summary

• The container entrypoint ran npx -y @osaas/cli@latest, a floating tag. It now runs a pinned version.
• ENV OSAAS_CLI_VERSION=4.35.0 is set in the Dockerfile, the only place the version appears. scripts/docker-entrypoint.sh reads it as "@osaas/cli@${OSAAS_CLI_VERSION:?...}" and fails fast if it is unset. config-to-env behaviour is otherwise unchanged.
• 4.35.0 was chosen as decided; npm view @osaas/cli version also reports 4.35.0.
• Added tests/test-entrypoint-cli-pin.sh: passing path (npx called with the pinned spec when set), failing path (unset version aborts and npx is never called), and checks that no @osaas/cli@latest remains and the version is pinned once.

Open PR #3 also changes scripts/docker-entrypoint.sh and the Dockerfile, including its own @osaas/cli@latest call, so whichever merges second will need a rebase on the config-to-env line.

Closes #4

Lessons

The single @latest call sits inside set -e command substitution, so the :? guard aborts the entrypoint only because of set -e; the test sources the line under set -e to reflect that.

What a human does next: Nothing.

🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com

[eyevinn-pr-reviewer]

Research Review

Verified

• Pin value: npm view @osaas/cli version and npm view @osaas/cli@4.35.0 version both return 4.35.0, so the pin exists and matches the ticket decision (issue #4 comment by birme).
• Occurrence sweep: on main, grep -rn "osaas/cli\|@latest" finds exactly one hit, scripts/docker-entrypoint.sh:90. The PR replaces it, so AC1 and AC2 hold. The version appears once, in ENV OSAAS_CLI_VERSION=4.35.0 in the Dockerfile.
• The Dockerfile is single-stage (FROM ${PYTHON_IMAGE}, ENTRYPOINT at the end). The ENV therefore reaches the entrypoint at runtime.
• ${VAR:?msg} inside the $(...) substitution under set -e aborts as the Lessons section says. I ran tests/test-entrypoint-cli-pin.sh on the PR head: 5/5 PASS, including the passing path (pinned spec reaches npx) and the failing path (unset version never runs npx).
• Overlap with PR #3: it touches the Dockerfile, the entrypoint, and tests/entrypoint_test.sh. The PR body discloses this, and the rebase need is the second merger's job.

Failing CI

• Failing check: build (workflow "Build and push Docker image"), run 41813030879. Log: failed to read dockerfile: open Dockerfile.osc: no such file or directory.
• It is pre-existing and unrelated to this diff. .github/workflows/docker.yml builds file: Dockerfile.osc, but main commit 47cb5af ("remove Dockerfile.osc from upstream") deleted it. The same check has failed on both main commits since 2026-07-06 (runs 28795814893, 28795780614).
• As a result, AC3 ("image build passes") cannot be shown by CI for this PR or any other. The Dockerfile change is a one-line ENV plus a comment, and I found no problem with it by reading.

Adjacent Stubs Detected

• None found in scripts/ or Dockerfile (no TODO/FIXME or undefined : undefined).

Orphaned Files Detected

• tests/test-entrypoint-cli-pin.sh is a standalone script with no CI hook. Main has no test workflow (PR #3 adds test.yml). Worth verifying, not blocking: wire it in when #3 lands.

Escape Hatch Coverage

• docker-entrypoint.sh:90 has a new fail-fast :? branch. It is reachable only if the image is built without the Dockerfile ENV, or the env is overridden to empty, which is a misconfiguration. A legitimate user is not blocked. The passing-path test exists in the test file (npx uses pinned spec).

Object Shape Verification

• No fetched or queried object is spread in this diff.

Contract diff

• No request handler or timeout changed. Files checked: Dockerfile, scripts/docker-entrypoint.sh, tests/test-entrypoint-cli-pin.sh. Runtime behaviour of config-to-env is unchanged other than the pinned version.

Impact Analysis

• Blast radius: only the config-service loading step in the container entrypoint.
• Downstream consumers: none in other repos.
• Coordinated changes needed: none. The sibling python-runner PR #34 uses the same pattern.
• Breaking change risk: low. Behaviour changes from "whatever is latest" to 4.35.0, which is the intent.

Risks Not Tested

• A real image build and container start could not be exercised because the Dockerfile.osc CI break is pre-existing. The test script simulates the extracted entrypoint line with a fake npx, not the real CLI at 4.35.0.
• That config-to-env behaves identically at 4.35.0 is assumed from it being the current latest.

Research Suggestions

• Separately fix docker.yml (Dockerfile.osc vs Dockerfile) so CI is meaningful. Not part of this PR.

Verdict

No blocking issues found.

---

Reviewed by PR Research Validator. This review checks whether code is based on verified sources rather than assumptions.

[eyevinn-developer]

CI-fix agent started for the failing checks (one cycle per PR). _daily-review Step 4.6_

[eyevinn-developer]

CI failure needs a human

The build check fails because .github/workflows/docker.yml builds Dockerfile.osc, which main deleted in 47cb5af (the check has failed on main since 2026-07-06). The fix is one line: change file: Dockerfile.osc to file: Dockerfile (same content as the removed file, plus this PR's OSAAS_CLI_VERSION pin). I could not push it: the eyevinn-developer App is refused for workflow files ("without workflows permission").

Please apply that line change to docker.yml on this branch, or push it with a token that has workflow scope.

Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com

[eyevinn-developer]

The one CI-fix cycle ran. The failing build check is inherited from main (docker.yml points at the deleted Dockerfile.osc) and the fix needs a push that touches .github/workflows/, which the developer App cannot do. No further fix agent will be spawned. See the comment on issue #4 for what is needed.

Needed now: push the one-line docker.yml change to this branch with workflow scope.
Cause category: missing permission/credential
Prevent next time: grant the eyevinn-developer App the workflows permission.
Owner of that change: birme