Von semantic-release zu semrel
Diese Anleitung richtet sich an Teams, die von semantic-release auf semrel migrieren.
Mapping auf einen Blick
Abschnitt betitelt „Mapping auf einen Blick“| semantic-release Bereich | semrel Entsprechung |
|---|---|
| Commit-Analyzer-Plugins | Analyzer-Plugin (analyzer-default / analyzer-conventional) |
| Release-Notes-/Changelog-Plugins | Generator-Plugins (generator-release-notes, generator-changelog-*) |
| npm/github/docker Publish-Plugins | Publisher-Plugins (publisher-oci, publisher-generic-http) + CI-Publish-Jobs |
Empfohlenes Rollout
Abschnitt betitelt „Empfohlenes Rollout“- Branch- und Trigger-Policy zunächst unverändert lassen.
- semrel im Dry-Run ergänzen und Version + Notes mit semantic-release vergleichen.
- Changelog/Release Notes auf semrel-Generatoren umstellen.
- Publishing von semantic-release auf semrel-Publisher migrieren.
- semantic-release Tagging/Publishing nach einem stabilen Zyklus deaktivieren.
Typische semrel-Basis
Abschnitt betitelt „Typische semrel-Basis“plugins: - uses: @semrel/github
- uses: @semrel/conventional
- uses: @semrel/release-notes
- uses: @semrel/changelog-md args: file: CHANGELOG.mdBeispiele für Publishing-Ersatz
Abschnitt betitelt „Beispiele für Publishing-Ersatz“- npm-Paketfluss:
npm publishim CI beibehalten, nachdem semrel Version und Changelog bestimmt hat. - GitHub-Release-Assets: Upload über CI-Schritt oder plugin-basiertes Publishing.
- OCI-/generische Artefakte:
@semrel/ocioder@semrel/generic-httpverwenden.
Risiken und Checks
Abschnitt betitelt „Risiken und Checks“- Sicherstellen, dass nur ein System Tags erstellt.
- Mindestens 10 aktuelle Commits im Dry-Run vergleichen, um Versions-Parität zu prüfen.
- Credentials in
SEMREL_PLUGIN_*Umgebungsvariablen verschieben.