Skip to content

release: propagate kit releases into the agent-runner image automatically #25

Description

@jorisjonkers-dev-agents

agent-runner bakes the kit at build time (services/agent-runner/Dockerfile: ARG AGENT_KIT_VERSION=v1.1.0, runtime-home pulled from GHCR or the release tarball) — and nothing updates that pin when the kit releases. The pin currently sits at v1.1.0 while the kit is at v3.3.0: every runner boots a kit two major versions stale.

The agents-api idle sweep already recycles disconnected runners when a new agents-api release ships, but that only re-pulls the same runner image; a kit release never reaches runners because no runner image rebuild is triggered.

Proposed wiring (pick one, both are cheap):

  • Renovate: a regex manager in agent-runtime matching ARG AGENT_KIT_VERSION= (and the runtime-home:vX.Y.Z ref) against agent-kit releases, grouped and automergeable — release → bot PR → merge → runner image release → existing recycle mechanism delivers it.
  • repository_dispatch: the kit's release workflow dispatches agent-runtime, whose workflow bumps the two pins and opens the PR itself (App-token authored, same pattern as the deploy platform's register-service job).

Either way the delivery chain closes end to end: kit release → runner image PR → CI → image release → agents-api marker recycle → fresh runners. Acceptance: cutting a kit release results, without human action, in an agent-runtime PR bumping both pins.

Related: boot-time freshness (companion issue) removes the urgency of this chain but image pins should still track releases for cold-start correctness.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions