ama-logs-update-charts-release-notes

ama-logs Release PR: Chart Bump + Release Notes

This skill prepares a release PR in microsoft/Docker-Provider that bumps the ciprod image tag across all Helm charts, Kubernetes manifests, and Dockerfiles, and adds a formatted entry to ReleaseNotes.md. It mirrors the structure used by recent release PRs (e.g. #1656 for 3.3.0, #1699 for 3.4.0).

Required Inputs

If the user did not provide OLD/NEW, read OLD from charts/azuremonitor-containerinsights/Chart.yaml (version: field) and ask for NEW.

Pre-flight: figure out what changed

Identify the PRs in this release

List every PR merged into ci_prod since the previous release's merge commit:

# Get the merge commit of the previous release PR (e.g. #1656 for 3.3.0)
gh pr list --repo microsoft/Docker-Provider --state merged --base ci_prod --search "<OLD> release notes in:title" --json number,mergeCommit,mergedAt

# Then list PRs merged after that date
gh pr list --repo microsoft/Docker-Provider --state merged --base ci_prod --search "merged:>=<DATE>" --json number,title,author,mergedAt --limit 100

For each PR, capture: number, title, author (login), and merged date.

Author attribution rules:

• Human authors: use their GitHub login verbatim, prefixed with @ (e.g. @zanejohnson-azure).
• Bot authors: gh pr view returns app/azure-monitor-assistant — strip the app/ prefix and write @azure-monitor-assistant.

Title rewriting: If a PR title is messy (e.g. branch-style Zane/fix fluentd procstat pattern), rewrite it to a clean conventional-commit-style title (fix: fluentd procstat pattern). Keep clean titles verbatim.

Classify each PR — Common vs Infra

This is the most error-prone step. Use these rules:

• Common (Linux + Windows) — anything that ships inside the ciprod image:
  • CVE fixes in gems/packages baked into the image (erb, jwt, etc.)
  • Go / Telegraf / Fluent-bit / Fluentd / MDSD / Windows AMA upgrades
  • Ruby/plugin code changes (e.g. fluentd config bugs)
• Infra — anything that does NOT ship in the image:
  • Pipeline/CI changes (release pipeline, build pipeline, e2e jobs)
  • Helm chart-only fixes that aren't bundled in the image
  • Documentation, test yamls, robot/automation workflows
  • Skill files

When in doubt: "does this change the bits inside ciprod:<NEW>?" If yes → Common. If no → Infra.

Get azurelinux and Ruby versions FROM THE CONTAINER

Do not copy these from the previous release entry. Pull the published ciprod:<OLD> image (or ciprod:<NEW> if it has already been built) and read them out — they may have shifted even if you didn't bump anything explicitly, because mcr.microsoft.com/azurelinux/base/core:3.0 is a floating base tag.

# Docker Desktop must be running. If not:
#   Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"
#   Start-Sleep -Seconds 60

docker pull mcr.microsoft.com/azuremonitor/containerinsights/ciprod:<OLD>
docker run --rm --entrypoint cat mcr.microsoft.com/azuremonitor/containerinsights/ciprod:<OLD> /etc/os-release | Select-String '^VERSION='
# => VERSION="3.0.20260517"

docker run --rm --entrypoint ruby mcr.microsoft.com/azuremonitor/containerinsights/ciprod:<OLD> -e "puts RUBY_VERSION"
# => 3.3.10  (x86_64 amalogs; the arm64 build may differ — keep both lines if so)

If ciprod:<NEW> is already published (CI built it), re-run against :<NEW> to confirm nothing shifted.

File edits — exact list

These eight files always change on a release. Do not add or remove files unless the user explicitly asks.

1. charts/azuremonitor-containerinsights/Chart.yaml

• version: <OLD> → version: <NEW>
• Leave appVersion alone unless the user says otherwise.

2. charts/azuremonitor-containerinsights/values.yaml

• imageTagLinux: "<OLD>" → "<NEW>"
• imageTagWindows: "win-<OLD>" → "win-<NEW>"
• tag: "<OLD>" → "<NEW>" (inside the amalogs.image block)
• tagWindows: "win-<OLD>" → "win-<NEW>"
• Do NOT touch agentVersion (MDSD) or winAgentVersion (Win AMA) unless those components were actually bumped this cycle.

3. charts/azuremonitor-containers/Chart.yaml

• version: <OLD> → version: <NEW>

4. charts/azuremonitor-containers/values.yaml

• tag: "<OLD>" → "<NEW>"
• tagWindows: "win-<OLD>" → "win-<NEW>"

5. charts/azuremonitor-containers-geneva/values.yaml

• tag: "<OLD>" → "<NEW>"

6. kubernetes/ama-logs.yaml

• Replace every mcr.microsoft.com/azuremonitor/containerinsights/ciprod:<OLD> with :<NEW>.
• Replace every :win-<OLD> with :win-<NEW>.
• Include commented-out blocks — prior release PRs update those too (e.g. the dev/test image comment).
• Do NOT touch agentVersion: annotations or RBAC rules unless the user explicitly asked.

7. kubernetes/linux/Dockerfile.multiarch

• ARG IMAGE_TAG=<OLD> → ARG IMAGE_TAG=<NEW>

8. kubernetes/windows/Dockerfile

• ARG IMAGE_TAG=win-<OLD> → ARG IMAGE_TAG=win-<NEW>

ReleaseNotes.md entry

Insert at the top of the ## Release History section, immediately below the heading and above the previous release's entry. Follow the exact format of the most recent prior entry. Keep one trailing blank line so entries are visually separated.

### <MM/DD/YYYY> -
##### Version mcr.microsoft.com/azuremonitor/containerinsights/ciprod:<NEW> (linux)
##### Version mcr.microsoft.com/azuremonitor/containerinsights/ciprod:win-<NEW> (windows)
- Linux
  - [azurelinux <AZL_VERSION>](https://github.com/microsoft/azurelinux/releases/tag/<AZL_VERSION>-3.0)
  - Golang - <GO_VERSION>
  - Ruby - arm64 - <RUBY_ARM64>, x86_64 - <RUBY_X86>
  - MDSD - <MDSD_VERSION>
  - Telegraf - <TELEGRAF_LINUX>
  - Fluent-bit - <FLUENTBIT_LINUX>
  - Fluentd - <FLUENTD>
- Windows
  - Golang - <GO_VERSION>
  - Ruby - <RUBY_WIN>
  - Windows AMA - <WIN_AMA>
  - Telegraf - <TELEGRAF_WIN>
  - Fluent-bit - <FLUENTBIT_WIN>
  - Fluentd - <FLUENTD>
##### Code change log
## What's Changed
- Common (Linux + Windows)
    * <Title> by @<author> in https://github.com/microsoft/Docker-Provider/pull/<num>
    * ...

- Infra
    * <Title> by @<author> in https://github.com/microsoft/Docker-Provider/pull/<num>
    * ...

Formatting rules:

• One PR per line. If multiple PRs share the same title (e.g. four Go upgrade auto-PRs), still emit one line per PR — do NOT consolidate.
• Always include the full https://github.com/microsoft/Docker-Provider/pull/<num> URL — not a markdown link.
• Use a blank line between the Common and Infra blocks.
• For dependency versions not bumped this cycle, copy the value from the previous entry but verify against the chart values files and the container — don't trust the prior entry blindly.

Verification before commit

Run from the repo root and confirm no stray old-version references remain in files that should have been bumped:

git --no-pager diff --stat
git --no-pager grep -n "<OLD>" -- charts kubernetes
git --no-pager grep -n "win-<OLD>" -- charts kubernetes

Remaining matches are acceptable only in:

• Older ReleaseNotes.md entries (anywhere outside the new entry).
• Test fixtures, scripts, or comments that intentionally pin <OLD>.

If anything else still references <OLD> under charts/ or kubernetes/, fix it before committing.

Commit, push, PR

One commit. Message:

<NEW> release notes and chart update

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Use the auto-created session branch (do not create a new branch manually). Push and open the PR against ci_prod:

git add charts kubernetes ReleaseNotes.md
git commit -m "<NEW> release notes and chart update`n`nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
git push 2>&1 | Select-Object -Last 5

Open the PR with the create_pull_request tool (or gh pr create):

• Title: <NEW> Release notes
• Base: ci_prod
• Body: brief summary mirroring the prior release PR — call out (1) image tag bump <OLD> → <NEW> across charts/manifests/Dockerfiles, (2) the release notes entry with dep changes, (3) which components are unchanged this cycle (e.g. MDSD, Windows AMA). Reference the previous release PR as the template.
• Not a draft.

Iteration: moving PRs between sections

Reviewers will often ask to reclassify or rename a PR entry after the initial PR is open. Make one focused commit per move/rename:

fix(release-notes): move #<num> <short title> to <Common|Infra> section

or

fix(release-notes): rename #<num> to "<new title>"

Always re-grep the file to make sure each PR appears in exactly one section after the move.

Important rules

• Never invent dependency versions. Pull them from the chart values files or the container.
• Never bump MDSD or Windows AMA versions unless the user explicitly says so — they are tracked in agentVersion / winAgentVersion and are decoupled from the ciprod tag.
• Never modify unrelated files (CI yamls, source code, RBAC rules) inside this skill's PR. Other PRs already in the release brought those changes — this PR is only the tag bump and the notes.
• Never mark the PR as draft.
• Keep edits idempotent: re-running the skill against the same OLD/NEW must not produce a second diff.