Zum Inhalt

Releases veröffentlichen

Releases werden durch das Pushen eines Git-Tags ausgelöst. Der Tag-Name bestimmt den Kanal.

Tag-Konventionen

Tag-Format Kanal GitHub-Release-Typ
v1.2.3-alpha.1 alpha Pre-release
v1.2.3-beta.1 beta Pre-release
v1.2.3-rc.1 rc Pre-release
v1.2.3 stable Latest release

Ein Release erstellen

# Alpha
git tag v1.2.3-alpha.1 && git push origin v1.2.3-alpha.1

# Beta
git tag v1.2.3-beta.1 && git push origin v1.2.3-beta.1

# Release candidate
git tag v1.2.3-rc.1 && git push origin v1.2.3-rc.1

# Stable
git tag v1.2.3 && git push origin v1.2.3

Der CI-Workflow (build-dmg.yml, benannt „Build Provisa Packages") wird bei jedem v*-Tag ausgelöst und führt folgende Jobs aus, die meisten davon parallel:

  1. Resolve release metadata — erkennt den Kanal anhand des Tag-Suffixes, leitet die PEP-440-Version und die Asset-Namen ab
  2. Download / package Trino plugins — lädt die Calcite-Trino-Connectors herunter und packt ein Tarball
  3. Pull core / obs / demo Docker images — speichert die Tarballs der Service-Images (arm64, plus amd64 core für die Windows-Container-Stufe)
  4. Build macOS Core / Obs / Demo DMGs — läuft auf macos-14 (Apple Silicon), airgapped
  5. Build Linux AppImage — core, airgapped
  6. Build Windows Core installer — nativ, eingebettetes Python, ohne Docker
  7. Build Windows Container-tier installer — WSL2 + Trino, ruft Images bei Bedarf ab (ohne VirtualBox/OVA)
  8. Build JDBC driver — Maven Shaded JAR
  9. Build and test Python client, dann Publish to PyPI
  10. Publish GitHub Release — lädt alle Assets hoch, setzt das Pre-Release-Flag für alpha/beta/rc

Release-Assets

Jedes Release veröffentlicht die folgenden Assets, alle am GitHub Release angehängt (das Wheel wird zusätzlich auf PyPI veröffentlicht):

Asset Plattform / Verwendung
Provisa-<tag>-macOS.dmg macOS Core (Apple Silicon, airgapped)
Provisa-Runtime-<tag>-macOS.dmg Natives macOS-Python-Runtime (neben Core zu mounten)
Provisa-Obs-<tag>-macOS.dmg macOS-Observability-Erweiterung
Provisa-Demo-<tag>-macOS.dmg macOS-Demo-Erweiterung (erfordert Obs)
Provisa-<tag>-linux-x86_64.AppImage Linux-x86_64-Core (airgapped)
Provisa-<tag>-windows-x64.exe Nativer Windows-x64-Installer (eingebettetes Python, ohne Docker)
Provisa-Container-<tag>-windows-x64.exe Windows-x64-Upgrade auf die Container-Stufe (WSL2 + Trino)
provisa-jdbc-<tag>.jar JDBC-Treiber — Tableau, PowerBI, DBeaver
provisa_client-<pep440>-py3-none-any.whl Python-Client (auch auf PyPI)
provisa-core-images-<tag>.tar.gz Tarballs der Core-Services-Images (arm64, airgapped)
provisa-core-images-amd64-<tag>.zip Core-Services-Images (amd64, Windows-Container-Stufe / airgapped)
provisa-obs-images-<tag>.tar.gz Images des Observability Stack (optional)
provisa-demo-images-<tag>.tar.gz Images des Demo Data Pack (optional)
provisa-trino-plugins-<tag>.tar.gz Connectors der Coordination Engine (SharePoint, Splunk, File)

Die Version des Python-Clients wird automatisch in das PEP-440-Format umgewandelt: v0.1.0-alpha.1 → 0.1.0a1, v0.1.0-beta.1 → 0.1.0b1, v0.1.0-rc.1 → 0.1.0rc1.

PyPI-Veröffentlichung einrichten (einmalig)

Die Jobs publish-pypi (provisa-client) und publish-provisa-pypi (provisa) in .github/workflows/build-dmg.yml veröffentlichen mit PyPI Trusted Publishing: Das GitHub-OIDC-Token des Jobs (id-token: write) authentifiziert ihn, und es wird kein API-Token gelesen. Registrieren Sie dieses Repository und build-dmg.yml für jedes Projekt auf pypi.org als Trusted Publisher (Your projects → Manage → Publishing). Die Veröffentlichungen laufen dann bei jedem Tag automatisch.

Signierung und Lieferkette

Was jedes Release-Artefakt trägt, so wie die Release-Workflows es bauen:

Artefakt Signatur
provisa und provisa-client auf PyPI Sigstore-signierte PEP-740-Attestation pro Datei (attestations: true), auf pypi.org prüfbar
provisa-pg-ext, provisa-duckdb-ext auf PyPI Sigstore-signierte PEP-740-Attestation pro Datei
JDBC-Treiber-.jar Sigstore-Build-Provenance-Attestation (actions/attest-build-provenance)
macOS-.dmg-Installer Developer-ID-Codesignatur und Apple-Notarisierung
Windows-.exe-Installer Nicht signiert
Linux-.AppImage Nicht signiert

Die signierte Installation auf jedem Betriebssystem ist pip install provisa: das Sigstore-attestierte PyPI-Paket. Ein Prüfer, der ein signiertes Artefakt unter Linux oder Windows braucht, installiert mit pip. Der Windows-Build signiert mit Authenticode, wenn ein Code-Signing-Zertifikat konfiguriert ist (WINDOWS_CERT_PFX_BASE64, WINDOWS_CERT_PFX_PASSWORD, WINDOWS_CERT_TIMESTAMP_URL, gelesen von packaging/windows/build-sfx.ps1); keines ist konfiguriert, daher wird er unsigniert ausgeliefert.

Abhängigkeiten und CVE-Gates:

  • Python-Abhängigkeiten sind mit Hashes in uv.lock gesperrt; CI installiert sie mit uv sync --frozen.
  • Der Workflow CVE Audit (.github/workflows/cve-audit.yml) führt pip-audit über die gesperrte Menge bei jedem Push auf main, bei jedem Pull Request und wöchentlich aus.
  • Beim Release erzeugen die Builds von provisa und provisa-client jeweils ein CycloneDX-SBOM und führen pip-audit über das Ausgelieferte aus. Der JDBC-Treiber wird mit grype --fail-on medium gescannt. Ein Fund lässt den Job fehlschlagen, und das Release veröffentlicht nichts: Die PyPI-Uploads und das GitHub-Release warten beide auf diese Jobs. Die SBOMs und CVE-Berichte werden an jedes Release angehängt.
  • Die Desktop-Installer bauen das provisa-Wheel auf dem Release-Runner aus dem Quellcode und lösen seine Abhängigkeiten zur Build-Zeit mit pip auf, nicht aus uv.lock; das CVE-Gate des Releases scannt die gesperrte Menge, nicht die gebündelten Abhängigkeiten der Installer.
  • Eine dokumentierte Ausnahme wird ignoriert: PYSEC-2026-4114 / CVE-2026-49265 (serverseitiges oauthlib-PKCE; Provisa verwendet oauthlib nur clientseitig).
  • packaging/pypi/requirements-embedded.lock ist eine Hash-gepinnte Auflösung von provisa[embedded] für Airgap-Mirrors (siehe packaging/pypi/MIRROR-CHECKLIST.md). Sie wird von Hand neu erzeugt, nicht pro Release.

Erforderliche Repository-Secrets

Konfigurieren Sie Folgendes unter Settings → Secrets → Actions:

Secret Erforderlich für Beschreibung
APPLE_CERT_P12_BASE64 Signierte Builds Base64-codierte .p12-Zertifikatsdatei (siehe unten)
APPLE_CERT_P12_PASSWORD Signierte Builds Beim Export des .p12 aus Keychain Access festgelegtes Passwort
APPLE_DEVELOPER_ID Signierte Builds Vollständiger Zertifikatsname: Developer ID Application: Your Name (TEAMID)
APPLE_NOTARYTOOL_APPLE_ID Notarisierte Builds E-Mail-Adresse der Apple ID
APPLE_NOTARYTOOL_PASSWORD Notarisierte Builds App-spezifisches Passwort von appleid.apple.com (nicht Ihr Anmeldepasswort)
APPLE_NOTARYTOOL_TEAM_ID Notarisierte Builds 10-stellige Apple-Team-ID

Builds ohne diese Secrets werden erfolgreich abgeschlossen, erzeugen jedoch ein unsigniertes/nicht notarisiertes DMG (Benutzer sehen eine Gatekeeper-Warnung).

Das .p12-Zertifikat exportieren

  1. Öffnen Sie Keychain Access → Anmeldeschlüsselbund → My Certificates
  2. Suchen Sie Developer ID Application: Your Name (TEAMID) — erweitern Sie den Eintrag, um zu bestätigen, dass der private Schlüssel darunter eingebettet ist
  3. Wählen Sie sowohl das Zertifikat als auch den zugehörigen privaten Schlüssel aus → Rechtsklick → Export 2 Items → als .p12 speichern → ein sicheres Passwort festlegen
  4. Base64-codieren und in die Zwischenablage kopieren:
base64 -i YourCert.p12 | pbcopy
  1. Fügen Sie den Wert als APPLE_CERT_P12_BASE64 ein; setzen Sie APPLE_CERT_P12_PASSWORD auf das Passwort aus Schritt 3

Den Namen Ihres Zertifikats finden

security find-identity -v -p codesigning | grep "Developer ID Application"

Kopieren Sie die vollständige Zeichenfolge in Anführungszeichen — das ist der Wert für APPLE_DEVELOPER_ID.

Ein fehlerhaftes Tag löschen

git tag -d v1.2.3-alpha.1
git push origin :refs/tags/v1.2.3-alpha.1

Löschen Sie anschließend das entsprechende GitHub Release in der Oberfläche, bevor Sie erneut taggen.