v0.65.2.dev5

chore(release): 0.65.2.dev5 — validate apk removal (apt+rpm only)

v0.65.2.dev4

chore(release): 0.65.2.dev4 — validate CloudFront no-cache metadata fix

v0.65.2.dev3

chore(release): 0.65.2.dev3 — validate deb/apk install fixes

v0.65.2.dev2

chore(release): 0.65.2.dev2 — re-validate apk + deb multi-arch fixes

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

v0.65.2.dev1

chore(release): 0.65.2.dev1 — dev tag to validate apk signing pipelin…

v0.65.1 — managed-repo deploy: remove git-bind-credential (misdiagnosis fix)

Patch release correcting a managed-repo data-app misdiagnosis from 0.65.0.

Fixed

• Removed data-app git-bind-credential (and its kbagent serve endpoint). It shipped in 0.65.0 on a misdiagnosis: managed-repo deploys were failing and we believed the platform did not inject the git-clone credential at deploy time, so the command wired an encrypted credential into parameters.dataApp.git. A clean reproduction on data-science.us-east4.gcp (against the sandboxes-service testManagedGitRepo.sh contract) confirmed the platform does inject the clone credential at deploy time — the command was unnecessary. The real fix was the 0.65.0 configVersion-omit change (pinning a managed app's no-git-block config is what made the runtime demand dataApp.git.repository and revert the deploy to stopped).
• Corrected the managed-repo guidance everywhere. The canonical flow to a running app is:

  data-app create --use-managed-git-repo
    -> git-credentials-create --type http_token --permissions readWrite  +  git push
    -> data-app deploy
  

  No credential wiring is needed — the platform injects the clone credentials. The earlier "could not read Username" / "platform doesn't inject credentials" framing was wrong (GitHub issue #454 closed as not-a-bug).

Unchanged (from 0.65.0, working as intended)

• data-app create --use-managed-git-repo, data-app runs, the configVersion-omit deploy fix, and the deploy-failure failure_reason surfacing.

v0.65.0 — managed git-repo deploy + install onboarding

New

• Deploy a data app from a Keboola-MANAGED git repository, end-to-end (#455). data-app create --use-managed-git-repo provisions an empty Keboola-hosted repo (writes no git block, forces --no-deploy; mutually exclusive with --git-repo and the --git-* / PAT flags). The full flow to a running app:

  data-app create --use-managed-git-repo
    -> git-credentials-create --type http_token --permissions readWrite  +  git push
    -> data-app git-bind-credential
    -> data-app deploy
  

  Verified live (a python-js tic-tac-toe app serving from its managed repo).
  • data-app git-bind-credential — mints an http_token on the app, encrypts it under the project KMS, and writes parameters.dataApp.git so the runtime can clone the managed repo at deploy. Required on stacks that do not inject managed-repo credentials at deploy time (otherwise the clone fails could not read Username and the deploy reverts to stopped). The token is encrypted in place and never printed; --dry-run previews what would be wired without minting the one-time credential.
  • data-app runs — lists deployment attempts with failure_reason + startup_logs, including setup-phase failures (e.g. a git-clone error) that produce no container logs. Works on never-started / failed apps where data-app logs returns HTTP 400 — the way to find out why a deploy reverted to stopped.
• First-run install onboarding (#446) — install.sh auto-installs uv when it is missing (opt out with KBAGENT_NO_UV_BOOTSTRAP=1), quiets the install output behind tidy step lines, and finishes with a Keboola banner + a "next steps" footer (kbagent project add, kbagent --help).

Fixed

• data-app deploy configVersion resolution. It now pins the latest Storage configVersion when a git block is present (external repos and a credential-wired managed repo) and omits it only for a pure managed repo (deploys from app.managedGitRepoId). Previously it always pinned, which pointed managed-repo deploys at a config snapshot with no git source and made them silently revert to stopped.

Improved

• data-app deploy --wait now auto-surfaces the latest run's failure_reason on timeout / state=error (best-effort, never masks the original error), with an actionable git-bind-credential hint for managed clone-auth failures — no more bare "timed out" with no reason.

REST API

• The managed-repo flow is mirrored 1:1 on kbagent serve: the use_managed_git_repo field on POST /data-app/{project}, GET /data-app/{project}/{app}/runs, and POST /data-app/{project}/{app}/git-repo/bind-credential.

---

Known platform dependency: on stacks that do not inject managed-repo credentials at deploy time, git-bind-credential is required for a managed-repo app to deploy. Tracked in #454.

v0.64.0 — data-app git-repo, serve --ui auth hardening, native distribution

New

• data-app git-repo introspection + managed-repo credentials — five data-app git-* commands over the sandboxes-service /apps/{id}/git-repo/* endpoints, mirrored 1:1 on the kbagent serve REST API:

  • git-repo — clone URLs (ssh / https) + a managed flag
  • git-branches — remote branches with commit metadata
  • git-entrypoints — root-level .py entrypoint files
  • git-credentials — list a managed repo's credentials
  • git-credentials-create — mint an SSH key / HTTP token (one-time secret for http_token)

  The read trio needs only the project storage token; the credential pair is managed-repo only (admin token). Gotcha: the introspection endpoints return 409 until the app has been deployed at least once — the git block syncs from the Storage config into the Data Science app record at deploy time.

Security

• kbagent serve --ui now decides which paths require auth via the router match protocol and fails closed — fixes the fastapi-0.137 nested-router bypass that served /doctor, /version, /changelog, and /agents unauthenticated (GHSA-ffpq-prmh-3gx2). The temporary fastapi<0.137 cap is lifted.

Fixed

• Invalid --mode / --poll-strategy (job run), --role / --default-role (project invite, member-set-role), and --role-hint (dev-portal identity) values fail with a clean exit-2 usage error again instead of an uncaught traceback (regressed under Typer ≥0.25's vendored Click; the choice options now use StrEnum).
• The interactive REPL help and tab-completion list every command again.

Changed

• kbagent now ships as a self-contained native binary via Homebrew / apt / dnf / apk / Chocolatey / WinGet (PyInstaller + nfpm distribution pipeline), alongside the existing pip / uv install.

Internal

• The data-app command and service layers were split into sibling modules (commands/_data_app_git.py, commands/_data_app_runtime.py, services/data_app_git_service.py) to keep data_app.py within the CONTRIBUTING.md file-size budget — no behavior change.
• Dependency bumps: cryptography 48, starlette 1.3, python-multipart 0.0.31, pyjwt 2.13.

---

Consolidates everything merged since the last published release v0.63.2. (Tags v0.63.3 / v0.63.4 exist but were never published as GitHub Releases — the native-distribution pipeline was being built/fixed in that window — so their contents ship to users for the first time here.)

v0.63.2 — document the in-process Python SDK

Docs: the in-process Python SDK is now documented

kbagent ships an importable Python SDK — from keboola_agent_cli import Client — for in-process use (a Keboola Data App, a transformation, a hosted service) with no CLI subprocess and no kbagent serve daemon. This release documents it end-to-end.

• docs/sdk.md — the deep guide: the Client facade vs the CLI vs the serve REST API, where the facade sits in the 3-layer architecture, a full method reference (query / query_result / run_job / config_detail / upload_table / files / raw), the typed result-model contract (extra="allow", populate_by_name, semver via __all__), py.typed, idempotent run_job, a gotchas cheat-sheet, and how to extend the SDK.
• examples/storage_tui/ — a runnable, dependency-free curses Storage browser driven entirely through the SDK.
• CONTRIBUTING.md gains an "Extending the importable SDK" section; fixed doc drift (dynamic APP_NAME, Python 3.12+, __init__ as the public SDK entrypoint).

No runtime code change — docs and examples ship in the repo, not the wheel, so the installed 0.63.2 package is functionally identical to 0.63.1.

v0.63.1 — self-update bridge for the PyPI rename

Fix: self-update repaired for users on <=0.62.0 (#424 / #439)

The PyPI rename keboola-agent-cli → keboola-cli broke kbagent update for every client already installed at <=0.62.0: it probed the release for the old wheel name, 404'd, fell back to a git+ build, and uv aborted with Executable already exists: kbagent — the failure was masked as "already up to date".

This release ships the migration bridge so those clients self-update in place:

• Legacy-named compat wheel — the release now carries keboola_agent_cli-0.63.1-py3-none-any.whl (identical code, distribution name unchanged) alongside keboola_cli-0.63.1-py3-none-any.whl, so the pre-0.63 self-update path finds its asset.
• Dynamic APP_NAME — kbagent version and the User-Agent work under either distribution name. The config dir (~/.config/keboola-agent-cli/) is unchanged.
• No more masking — a failed kbagent update now reports update FAILED: <reason> instead of "already up to date".

Stuck on 0.62.0 and not auto-updating?

One-time manual upgrade:

uv tool uninstall keboola-agent-cli
uv tool install 'keboola-cli @ https://github.com/keboola/cli/releases/download/v0.63.1/keboola_cli-0.63.1-py3-none-any.whl'
# add [server] extras if you originally installed with them:
#   'keboola-cli[server] @ <same wheel URL>'