Repository-Umzug zu Zebroo Tools
Das Entwicklungsrepository liegt unter zebroo-tools/zebroo-sync. Die bisherigen Git-Adressen werden von GitHub weitergeleitet. Bestehende Checkouts können auf die neue Adresse umgestellt werden:
git remote set-url origin git@github.com:zebroo-tools/zebroo-sync.git
Die zugehörigen Tools und wiederverwendbaren Workflows liegen ebenfalls in
zebroo-tools. Das Stable-Repository bleibt unter Odoo-Ninjas/zync-stable. Gimera verwendet die neuen Adressen;
die vorhandenen Versionszweige und Commit-Pins bleiben erhalten.
GitHub Actions unterstützt keine Weiterleitung von uses:-Verweisen.
Aufrufende Workflows müssen deshalb zebroo-tools/git-workflows verwenden.
Die Test-Workflows sind auf einen Commit gepinnt, der auch seine internen Actions über die neue Organisation lädt. Der Workflow-Generator verwendet dieselben Verweise, damit eine Neugenerierung sie nicht zurücksetzt.
Repository-Secrets, Deploy-Keys, Webhooks und die sechs Repository-Runner wurden beim Transfer übernommen. Frühere Team-Berechtigungen werden als Repository-Zugriffe wiederhergestellt; betroffene Benutzer müssen die neuen GitHub-Einladungen annehmen.
Ein PR-Check auf ubuntu-latest prüft während der Migration, ob GitHub-hosted
Runner in der Zielorganisation starten. Die vorhandenen Test-Workflows prüfen
die selbst gehosteten Runner und die eingebundenen Abhängigkeiten.
Automatische Änderungen am Entwicklungszweig
Auf 19.0 verarbeitet zuerst patchnotes to changelog die Patchnotes und
Versionsänderungen. Erst nach erfolgreichem Abschluss dieses Workflows starten
die Lizenz- und Cleanup-Jobs über workflow_run. Dadurch konkurrieren sie
nicht mehr mit der Patchnote-Verarbeitung um dieselben Modulmanifeste.
Fehlgeschlagene Läufe und Läufe aus fremden Repositorys starten diese Jobs nicht.
Der Lizenzjob verwendet den dann aktuellen Standardzweig. Ein normaler Push bleibt die Sicherung gegen Änderungen, die danach noch eintreffen: bei einem weiteren Konflikt wird nichts erzwungen. Die vollständige Integration und das Stable-Deployment müssen weiterhin anhand ihres eigenen Laufs geprüft werden.
Prüfung der automatischen Versionsverteilung
Die Verteilung bereitet Merge-PRs vor, ohne gemeinsame Versionszweige per Rebase oder Force-Push zu ersetzen. Konflikte und abgelehnte Pushes lassen den Job fehlschlagen; ein erstelltes Issue gilt nicht als erfolgreiche Verteilung. Bereits integrierte Quellen erzeugen keinen weiteren PR. Vor der Übernahme sind die Zielversion, die bestehende Historie und die Modulverträge zu prüfen.
Der aufrufende Repository-Token benötigt Schreibrechte für Inhalte, Pull Requests und Issues. GitHub Actions muss im Repository Pull Requests erstellen dürfen. Diese Einstellung ist bei Vorbereitung der Änderung deaktiviert und muss vor Aktivierung geprüft und freigegeben werden. Die vorhandene SSH-Secret-Zuordnung und die Versionsziele bleiben erhalten.