[Lufftre]

Why

My Jobs supports named workspace git credentials, but the python-job-runner service only takes a raw GitHubToken. And today the runner loads the parameter store before installing dependencies and running setup.sh, so repository code that runs at install time (build backends, setup.py, setup.sh) sees every parameter-store secret plus the runner's own tokens. WORKER_CMD can't protect against that, because it runs last.

What changes

• GIT_CREDENTIAL: the name of a workspace git credential (user.gitcred.<name>). The runner resolves it via GET deploy.svc.<env>.osaas.io/mytenantsecrets/user.gitcred.<name> with OSC_ACCESS_TOKEN, used only when no GIT_TOKEN/GITHUB_TOKEN is set. The token goes into the clone URL only (origin is reset to the clean URL afterwards); it is never logged or exported to the worker. An unknown name or failed lookup fails the run before anything executes.
• Commit pinning: a full commit SHA as the URL fragment (…/repo#<40 or 64 hex>) is checked out after a normal clone, since git clone -b accepts only branches and tags. A missing commit fails the run. Branch/tag fragments behave as before.
• Run order: clone → install dependencies and setup.sh (with OSC_ACCESS_TOKEN, GIT_TOKEN, GITHUB_TOKEN removed from their environment) → load the parameter store → run the worker. The worker's environment is unchanged from today.
• Fixes: under set -e, a store with no export lines aborted the run, and a failed config load exited without the error message; both are handled now. jq is installed (the token refresh already called it).
• tests/entrypoint_test.sh plus a Test workflow; README documents the variables and run order.

Backwards compatible: existing SOURCE_URL, GIT_TOKEN/GITHUB_TOKEN, CONFIG_SVC, SUB_PATH, WORKER_CMD behave the same, except that install-time code no longer sees parameter-store values. A job whose setup.sh relied on store values would need to move that into the worker.

Platform work still needed

• Catalog schema: add a GitCredential option to eyevinn-python-job-runner that maps to GIT_CREDENTIAL, next to GitHubToken. The service's Dockerfile.osc lives in the eyevinn-osaas fork, so it should pick up jq too.
• Token scope: the runner's OSC_ACCESS_TOKEN must be allowed to read GET /mytenantsecrets/user.gitcred.*. If runner tokens shouldn't read tenant secrets, the deploy manager could instead resolve the credential at instance creation and inject it as GIT_TOKEN, as it does for My Jobs; the runner side here works either way.
• Note: docker.yml builds Dockerfile.osc, which was removed from this repo, so that workflow fails on PRs independent of this change.

Testing

• bash tests/entrypoint_test.sh: URL/ref parsing, SHA detection, credential-name validation, credentials removed from the install environment, setup.sh runs before config is loaded.
• Built the image and ran it: pinned to 42670c9… (checked out that commit), #main (branch), a nonexistent SHA (fails, exit 1), and GIT_CREDENTIAL with an invalid token (fails with HTTP 401 before running the worker). Not tested against a real registered credential or a live runner token.

🤖 Generated with Claude Code