Implements a new release strategy for agent container images that aligns with CLI versioning and automates the image build process during releases.

Closes: #241

Overview

This PR introduces a complete overhaul of how agent images are versioned, built, and distributed. The key improvement is automatic synchronization between the CLI version and the agent image version, ensuring consistency across the Rover ecosystem.

Key Changes

1. Image Renaming & Restructuring

• Renamed container image from ghcr.io/endorhq/rover/node to ghcr.io/endorhq/rover/agent for clarity
• Moved image files from images/node/ to images/agent/ directory
• Updated all references in Dockerfiles, workflows, and documentation

2. Dynamic Image Resolution

• Introduced getDefaultAgentImage() function that dynamically resolves the correct image based on CLI version
• Development mode (versions with -dev suffix): Always uses ghcr.io/endorhq/rover/agent-dev:latest
  • Dev image ONLY ever uses the latest tag (never version tags)
  • Automatically updated on every push to main branch
• Production mode (release versions): Uses ghcr.io/endorhq/rover/agent:v{version}
  • Production image uses specific version tags (e.g., v1.5.2)
  • Built during release workflow
• Environment override: Respects ROVER_AGENT_IMAGE environment variable for custom images
• Removed hardcoded AGENT_IMAGE constant in favor of dynamic resolution

3. Workflow Enhancements

Build Image Workflow (build-image.yml)

• Added workflow_call trigger for reusability in other workflows
• Added configurable image-name input parameter (defaults to ghcr.io/endorhq/rover/agent)
• Supports building both production (agent) and development (agent-dev) images

CLI Workflow (cli.yml)

• New: Automatic dev image build on push to main
• Builds agent-dev:latest after successful CLI builds
• Ensures dev image stays in sync with CLI changes
• Important: Only pushes latest tag to agent-dev, never version tags

Release Workflow (release.yml)

• New: Builds production agent image before CLI release
• Creates/updates release branches following release/{project}/v{major.minor} pattern
• Automatically tags production images with version (e.g., v1.5.2)
• Only builds image for CLI releases (not extension releases)
• Version tags only pushed to production agent image, never to agent-dev

4. Release Branch Management

• Automatic creation of release branches with pattern: release/cli/v{major.minor}
• Automatic updates to existing release branches for patch releases
• Example: Version 1.5.2 → branch release/cli/v1.5
• All release commits and tags go to the release branch, not main

5. Version Management

• Reset package versions to 0.0.0-dev for development mode
• CLI and extension versions now start at 0.0.0-dev on main branch
• Actual version numbers only exist on release branches and tags

6. Documentation Updates

• Updated docs/agent-images.md to reference new images/agent/ path
• Updated docs/ai-agents.md with correct image build instructions

Image Tagging Strategy

Development Image (agent-dev)

• Registry: ghcr.io/endorhq/rover/agent-dev
• Tags: ONLY latest (never version tags)
• Updated: On every push to main branch
• Usage: Automatic when CLI version contains -dev (e.g., 0.0.0-dev)

Production Image (agent)

• Registry: ghcr.io/endorhq/rover/agent
• Tags: Specific versions (e.g., v1.5.2)
• Updated: During release workflow
• Usage: Automatic when CLI version is a release version (e.g., 1.5.2)

Release Flow

The new automated release process works as follows:

1. Image Build: Build and publish production agent image with version tag (e.g., v1.5.2)
2. Branch Management: Create or update release branch (e.g., release/cli/v1.5)
3. Version Bump: Update package.json to target version
4. Image Sync: Dynamic resolution ensures CLI uses correct versioned image
5. Commit & Tag: Commit changes to release branch and create git tag
6. Publish: Publish CLI package to npm
7. GitHub Release: Create GitHub release with changelog

Benefits

• Version consistency: CLI and agent image versions are always synchronized
• Improved traceability: Each CLI release version is tied to a specific agent image
• Simplified development: Dev builds automatically use agent-dev:latest
• Clear separation: Dev and production images are completely separate
• Better release management: Release branches provide stability for patches
• Reduced manual work: No need to manually update image constants

Testing

• Dev image builds automatically on push to main (always tagged as latest)
• Production image builds during release process (tagged with version)
• Both images support multi-platform builds (linux/amd64, linux/arm64)