Publishing
Release erstellen
Ready Build zu formaler Version promoten. Versionsnummer wird in diesem Moment fixiert.
POST
Release erstellen
POST https://api-datahub.octoparse.com/v1/data-apps/{app_id}/releases
Authentifizierung: API-Schlüssel erforderlich (Authorization: Bearer <API Key>). Nur App-Autor; andere erhalten 404.
Befördert einen angegebenen Build im Status ready zu einer offiziellen Version. Die Versionsnummer wird hier festgelegt: Standardmäßig wird das Patch-Segment der aktuell höchsten Version um eins erhöht (das erste Release ist 0.1.0). Eine explizite Version muss aus drei numerischen Segmenten bestehen und strikt größer als die aktuell höchste sein – nutzen Sie sie für Major- oder Minor-Sprünge.
Vorbedingungen: der Build existiert und ist ready; der Snapshot läuft erneut durch die Validierungspipeline (Specs können sich während der Build-Lebenszeit geändert haben); wenn expected_revision gesetzt ist, darf der Workspace keine parallelen Edits haben. Parallele Publishes werden über die Unique-Constraint auf (Publisher, App-Name, Version) arbitriert; bei Auto-Version-Konflikten rechnet die Engine neu und retried einmal. Nach dem Publish bleibt der Workspace erhalten — er kann dem released Snapshot bereits voraus sein.
Anfrage
Pfadparameter
string
erforderlich
App-Referenz.
Anfrage-Body
string
erforderlich
Zu veröffentlichende Build-ID. Muss ready sein.
string
Explizite dreiteilige Version. Weglassen, um das Patch-Segment zu erhöhen.
integer
Expected current draft revision. Mismatch gibt zurück
409.Beispielanfrage
Antwort
200 Erfolg
data gewrappt. Felder:
string
erforderlich
—
string
—
string
erforderlich
Veröffentlichte Versionsnummer.
string
erforderlich
Zugehöriger Build.
string
Veröffentlichungszeit.
string[]
—
Fehler
Fehlerantworten nutzen
{"error": {code, category, message, retryable}}. Siehe Fehler.