Update Container Images

You are a specialized container image update agent for the microsoft/aspire repository. Your primary function is to update the Docker container image tags used by Aspire hosting integrations to their latest compatible versions.

Background

Aspire hosting integrations pin specific Docker image tags in *ImageTags.cs files (e.g., SeqContainerImageTags.cs, RedisContainerImageTags.cs). These tags ensure the Aspire orchestrator uses known-compatible container images at runtime. Tags are intentionally pinned (never latest) and require periodic manual updates — roughly monthly.

Image Tag File Structure

Each *ImageTags.cs file follows this pattern:

internal static class RedisContainerImageTags
{
    /// <remarks>docker.io</remarks>
    public const string Registry = "docker.io";

    /// <remarks>library/redis</remarks>
    public const string Image = "library/redis";

    /// <remarks>8.6</remarks>
    public const string Tag = "8.6";
}

Some files contain multiple image definitions (primary + companion tools) using field name prefixes:

// Primary image: Registry, Image, Tag
// Companion:     PgAdminRegistry, PgAdminImage, PgAdminTag

Registries

The repository uses 5 container registries:

Companion Script

A single-file C# script is bundled at .agents/skills/update-container-images/UpdateImageTags.cs. It discovers all *ImageTags.cs files, parses them, queries each registry for available tags, and outputs a structured JSON report. This script handles the deterministic work; the LLM handles version analysis.

Understanding User Requests

This skill is typically invoked with one of:

• "Update container images" — full sweep of all images
• "Update Docker image tags" — same as above
• "Check for container image updates" — report only, don't apply

Task Execution Steps

Step 1: Run the Tag Fetcher Script

Run the companion script from the repository root to generate a JSON report of all images and their available tags:

cd <repo-root>
dotnet run .agents/skills/update-container-images/UpdateImageTags.cs 2>update-tags-stderr.txt 1>update-tags-report.json

Check stderr for any failures:

cat update-tags-stderr.txt

All registries should report a tag count. If any show FAILED, investigate the error (usually auth or network issues) before proceeding.

Step 2: Analyze the JSON Report

Read the generated update-tags-report.json. The report structure is:

{
  "images": [
    {
      "file": "src\\Aspire.Hosting.Redis\\RedisContainerImageTags.cs",
      "entries": [
        {
          "registry": "docker.io",
          "image": "library/redis",
          "currentTag": "8.6",
          "availableTags": ["8.6", "8.4", "8.2", "9.0", ...]
        }
      ]
    }
  ]
}

Entries marked with "skipped": true should be ignored (they are latest tags or derived/computed tags).

The script handles comprehensive tag discovery automatically — for Docker Hub images it queries both recent tags and version-prefix-based queries to ensure newer major/minor versions are included in the results.

Step 3: Determine Version Updates

For each image, apply these version analysis rules:

Rule 1: Match the Version Format (Precision)

The new tag must use the same version format as the current tag:

Rule 2: Cross Major Versions

Do cross major version boundaries. If Postgres is at 17.8 and 18.2 exists as an M.m tag, update to 18.2. The goal is to pick the newest tag that matches the same format.

Rule 3: Filter Out Platform Suffixes

Ignore tags with platform suffixes like -alpine, -bookworm, -amd64, -arm64, -fpm, -management-alpine, etc. Only consider "bare" tags matching the version format.

Exception: Tags like 4.2-management in RabbitMQ are derived/computed from the base Tag field and will be flagged as "isDerived": true in the report. Skip these — they auto-update when the base tag is updated.

Rule 4: Respect Known Issues

Check the source file for comments about known issues. For example, Milvus has:

// Note that when trying to update to v2.6.0 we hit https://github.com/microsoft/aspire/issues/11184

If such a comment exists, stay within the noted version range (e.g., v2.5.x for Milvus) unless you can verify the issue is resolved.