prepare-core-kit-release

Prepare Core Kit Release

Bereitet das bottlerocket-core-kit Repository für eine neue Veröffentlichung vor, indem die Version in der Twoliter.toml erhöht und die CHANGELOG.md aktualisiert wird.

Zweck

Automatisiert den Release-Vorbereitungs-Workflow für bottlerocket-core-kit:

• Erhöht die Release-Version in der Twoliter.toml
• Generiert Changelog-Einträge aus dem Git-Verlauf
• Erstellt korrekt formatierte Commits für die Veröffentlichung

Wann verwenden

• Vorbereitung einer neuen Veröffentlichung von bottlerocket-core-kit
• Changelog muss mit aktuellen Änderungen aktualisiert werden
• Erstellung von Release-Commits mit korrekter Formatierung

Voraussetzungen

• Arbeiten in einem Grove mit ausgechecktem bottlerocket-core-kit
• Git-Verlauf verfügbar mit Merge-Commits und PR-Referenzen
• Kenntnis der Ziel-Release-Version

Vorgehensweise

Release-Workflow

WICHTIG: Der Release-Prozess erfordert ZWEI Commits in strenger Reihenfolge:

Commit 1: Version-Bump (MUSS zuerst kommen)

Aktualisiert Twoliter.toml, um die neue Release-Version zu setzen:

# In Twoliter.toml, update:
release-version = "X.Y.Z"

Commit-Befehl:

git add Twoliter.toml && git commit -s -S -m "twoliter: bump kit version to vX.Y.Z"

Commit 2: Changelog-Update (MUSS als Zweites kommen)

Aktualisiert CHANGELOG.md mit den Änderungen der neuen Version.

Commit-Befehl:

git add CHANGELOG.md && git commit -s -S -m "changelog: update for vX.Y.Z"

1. Neue Commits identifizieren

• Finde Commits seit dem letzten Changelog-Eintrag mit: git log --oneline <last_version_tag>..HEAD
• Falls keine Tags existieren, verwende: git log --oneline --since="<last_release_date>"

2. PR-Referenzen finden

• Analysiere Merge-Commits, um PR-Nummern zu finden: git log --merges --oneline <last_version_tag>..HEAD
• Suche nach Mustern wie "Merge pull request #XXX" in Commit-Nachrichten
• Gleiche Commit-Hashes mit PR-Merge-Commits ab

3. KRITISCH: PR-Inhalte überprüfen

Überprüfe IMMER, welche Pakete/Änderungen in jedem PR enthalten sind, indem du die tatsächlich geänderten Dateien ansiehst:

git show <merge_commit_hash> --stat

Verlasse dich NICHT auf:

• Commit-Nachrichten-Zusammenfassungen allein
• PR-Branch-Namen
• Annahmen darüber, was ein PR enthält

ACHTE AUF GEMISCHTE PRs: Ein einzelner PR kann sowohl First-Party-Änderungen ALS AUCH Third-Party-Paket-Updates enthalten. Du musst für jede Änderungsart aus demselben PR separate Changelog-Einträge erstellen.

Beispiel eines gemischten PRs (PR #760):

git show 70609d6a --stat
# Zeigt Änderungen an:
#   sources/host-ctr/...          <- First-Party-Änderung (host-ctr Resolver)
#   packages/amazon-vpc-cni-plugins/...  <- Third-Party-Update
#   packages/ecs-agent/...        <- Third-Party-Update

Dieser PR erfordert ZWEI Changelog-Einträge:

1. OS Changes: "Replace amazon-ecr-containerd-resolver with Docker resolver in host-ctr ([#760])"
2. Third Party Package Updates: "Update amazon-vpc-cni-plugins, ecs-agent ([#760])"

Beispiel für korrekte Überprüfung:

# Für Merge-Commit 9656d841 (PR #795):
git show 9656d841 --stat
# Zeigt: libcap, liburcu, libxcrypt, readline Änderungen
# NICHT das, was Branch-Name oder Zusammenfassung suggerieren

4. Changelog-Stilrichtlinien

Abschnitts-Header

# v<VERSION> (<YYYY-MM-DD>)

Gliederung der Abschnitte

1. OS Changes - Core-System- und First-Party-Paket-Updates
   • First-Party-Paketupdates (mit detaillierten Unterpunkten)
   • Third Party Package Updates Unterabschnitt für externe Pakete
2. Build Changes - Build-System-, Tooling- und Infrastrukturänderungen
3. Orchestrator Changes - Container-Orchestrierungsspezifische Änderungen
   • Kubernetes Unterabschnitt, falls zutreffend

Eintragsformat

• Verwende Aufzählungspunkte mit PR-Referenzen: - Description ([#XXX])
• Füge bei First-Party-Paketen bei Bedarf detaillierte Unterpunkte hinzu
• Bei Third-Party-Paketupdates: KEINE Versionsnummern angeben
  • RICHTIG: - Update \docker-cli-29`, `docker-engine-29` ([#785])`
  • FALSCH: - Update \docker-cli-29` auf v29.0.4, `docker-engine-29` auf v29.0.4 ([#785])`
• Bei Patches/Fixes verwende "Patch" anstelle von "Update":
  • RICHTIG: - Patch \containerd-2.1` to update GRPC ([#801])`

Kategorisierungsregeln

• First-Party-Pakete: Bottlerocket-spezifischer Code und interne Abhängigkeiten
• Third-Party-Pakete: Externe Bibliotheken und Tools (glibc, docker-engine, usw.)
• Build changes: Alles, was das Build-System, CI/CD oder Entwicklungswerkzeuge betrifft
• Orchestrator changes: Kubernetes, ECS oder andere Container-Orchestrierungsfunktionen

5. Qualitätsprüfungen

• Stelle sicher, dass alle Einträge PR-Referenzen im Format ([#XXX]) haben
• Überprüfe konsistente Formatierung und Einrückung
• Gruppiere zusammenhängende Änderungen, um repetitive Einträge zu vermeiden
• Halte die chronologische Reihenfolge innerhalb der Abschnitte ein
• Überprüfe, ob die Unterabschnitts-Header den vorhandenen Mustern entsprechen
• Überprüfe den tatsächlichen Inhalt jedes PR, bevor du den Eintrag schreibst

Validierung

Validierungsbefehle

• Überprüfe den Git-Log-Bereich: git log --oneline <range>
• Überprüfe Merge-Commits: git log --merges --grep="pull request" <range>
• Überprüfe PR-Inhalte: git show <merge_hash> --stat
• Validiere, dass die PR-Nummern im Repository existieren

Eine erfolgreiche Release-Vorbereitung umfasst:

• Zwei Commits in korrekter Reihenfolge (zuerst Version-Bump, dann Changelog)
• Twoliter.toml enthält die aktualisierte release-version
• CHANGELOG.md enthält einen neuen Versionsabschnitt mit korrektem Datum
• Alle Einträge haben PR-Referenzen im ([#XXX]) Format
• Third-Party-Paketupdates enthalten KEINE Versionsnummern
• Commits sind signiert (-s -S Flags)

Häufige Probleme

Fehlende PR-Referenzen

Wenn Merge-Commits keine PR-Nummern anzeigen, überprüfe:

git log --merges --oneline | head -20

Suche nach "Merge pull request #XXX" Mustern.

Falsche Paketkategorisierung

Überprüfe immer mit git show <hash> --stat, um die tatsächlich geänderten Dateien zu sehen, bevor du als First-Party vs. Third-Party kategorisierst.

Versionsnummer in Third-Party-Updates

Denke daran: Einträge für Third-Party-Paketupdates sollten KEINE Versionsnummern enthalten, sondern nur Paketnamen.

Beispiel Ausgabestruktur

# v12.3.0 (2026-01-20)

## OS Changes
- Replace `amazon-ecr-containerd-resolver` with Docker resolver in `host-ctr` ([#760])
- Add MPS control daemon support to `nvidia-k8s-device-plugin` ([#789])

### Third Party Package Updates
- Update `docker-cli-29`, `docker-engine-29` ([#785])
- Patch `containerd-2.1` to update GRPC ([#801])
- Update `libnvme`, `xfsprogs`, `nvme-cli`, `makedumpfile`, `keyutils`, `e2fsprogs` ([#794])
- Update `readline`, `libxcrypt`, `liburcu`, `libcap` ([#795])

[#760]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/760
[#785]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/785
[#789]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/789
[#794]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/794
[#795]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/795
[#801]: https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/801