Native + OTA Kanalablauf

Eine häufige Capgo-Einrichtung verwendet einen dev Kanal und einen Produktionskanal channel. CI lädt jeden OTA-Bundle hoch. devDann wird es auf production Kanal. CI lädt alle OTA-Pakete hoch und --fail-on-incompatible So kann der CI kein live update bereitstellen, das neue native code benötigt.

Diese Seite beantwortet die folgende Frage: was tun Sie, wenn Sie absichtlich einen Bundle benötigen, der mit den aktuellen native Paketen des Kanals nicht kompatibel ist?

Wenn Sie den Hintergrund, warum Capgo native Pakete vergleicht, benötigen, beginnen Sie mit Native KompatibilitätFür eine vollständige CI-Zweig, die OTA vs Capgo Build automatisch auswählt, siehe Auto OTA oder Native.

Auto OTA oder Native

Abschnitt mit dem Titel "Empfohlener Kanalayout" dev and production Kanäle existieren bereits. Erstellen Sie sie zuerst, wenn nötig:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

Kanal	Wer erhält es	Wer bekommt es?
dev	Typische Uploads	Jeder CI-Push von JS (und absichtliche native Baselines)
production	Store users	Nur veröffentlicht, wenn releasefertig.

--fail-on-incompatible ein gutes Standard auf beiden Kanälen für alltägliche OTA-Uploads. Es vergleicht die native Pakete in der zu hochladenden Bundle mit dem aktuellen Bundle auf diesem Kanal. aktuell im laufenden Betrieb auf diesem Kanal. If they differ, the upload exits non-zero and nothing ships.

Abschnitt mit dem Titel “Alltags-OTA (Flag behalten)”

Wenn die Änderung nur JavaScript betrifft und native Pakete dem Kanal entsprechen:

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible Verhindere unbeabsichtigte native Abweichungen. --auto-min-update-version ist erforderlich bei jeder Uploadsitzung, sobald der Kanal verwendet metadata When the change is JavaScript-only and native packages match the channel: metadata Terminal window --auto-min-update-version bis Sie umschalten.

Optional CI-Sperre vor dem Upload:

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

Absichtliche native Bump (die Flagge einmal fallen lassen)

Sie kann ein Bundle hochladen, das neue native code benötigt, während man --fail-on-incompatibleDass Flag existiert, um genau diesen Fall zu blockieren. Wenn ein Plugin, Capacitor-Version oder andere native Abhängigkeit absichtlich geändert wurde:

1. Versenden Sie das entsprechende native Binärdatei (App Store / Play Store, oder) Capgo Build).
2. Laden Sie das entsprechende JS-Bundle hoch without --fail-on-incompatible.
3. Prefer --auto-min-update-version mit dem Kanal auf der metadata Geräte, die noch auf dem alten Binärdatei stehen, erhalten das neue Bundle nicht, bis sie die neue App installieren.
4. Nachdem diese Basisupload erfolgt ist, fügen Sie --fail-on-incompatible wieder auf normale OTA CI (und behalten Sie) --auto-min-update-version während der Kanal weiterhin auf metadata).

1. Einmalig pro Kanal: Metadaten-Zugriff aktivieren

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   Wiederholen für dev Wenn das Kanal auch absichtliche native Baselines erhält. Nach diesem Wechsel müssen alle Uploads zum Kanal --auto-min-update-version oder --min-update-version.

2. Versenden Sie das native Binärpaket

   Die iOS/Android-App erstellen und hochladen, die die neuen Plugins oder native Änderungen enthält. Bis die Benutzer diese Binärdatei installieren, können sie eine Abhängigkeit von diesen native Paketen nicht sicher ausführen.

3. Die entsprechende OTA-Basis hochladen (keine) --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   Dies registriert die neuen native Pakete auf dem Kanal. Später bundle releaseType / --fail-on-incompatible Die geschützten OTA-Uploads fortsetzen

4. Wiederholen geschützte OTA-Uploads

   Nachfolgende JS-only-Veröffentlichungen verwenden beide Flags wieder:

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

Tipp

Behandeln Sie die native-baseline-Uploads als eigenständige CI-Aufgabe (oder einen manuellen Release-Schritt), nicht als Ausnahme, die Sie in die Standard-OTA-Aufgabe einstreuen. --fail-on-incompatibleund auf eine metadata channel sollte es auch aufbewahren --auto-min-update-version.

FAQ

Kann ich das --fail-on-incompatible und kann ich trotzdem ein natives-inkompatibles Bundle pushen?

Nein. Wenn die native Pakete des Uploads von den Paketen des Live-Bundles des Kanals abweichen, versagt der Flag auf Absicht die Befehlsausführung. Für einen bewussten natives Anstieg, lassen Sie den Flag auf diesem einen Upload aus (und verwenden Sie --auto-min-update-version wenn Sie können).

Stellt eine einmalige Upload ohne den Flag die richtige Vorgehensweise dar?

Ja. Das ist die unterstützte Methode, um die native Basislinie des Kanals nach dem Versand eines neuen Binärs voranzutreiben. Halten Sie den Flag auf jedem anderen OTA-Upload so, dass unbeabsichtigter natives Anstieg immer noch CI versagt.

Muss ich hochladen zu dev zuerst, dann production?

Ja, wenn das Ihrem Prozess entspricht. Führen Sie die gleichen Regeln pro Kanal: Die Kompatibilitätsprüfung erfolgt gegen das aktuelle Live-Content auf dem Zielkanal. Verschieben oder hochladen Sie production nur nachdem dev schaut gut aus, und verwenden Sie eine native-Baseline-Hochladung (kein --fail-on-incompatible) auf jedem Kanal, der die neuen native Pakete aufzeichnet.

Wie verhält es sich, wenn ich das neue native Bundle mit der Flagge noch hochlade?

CI fehlschlägt und Capgo lässt das Hochladen nicht durch. Das ist die erwartete Ausgabe. Entweder war der Wechsel versehentlich (korrigieren Sie die native Pakete und versuchen Sie es erneut als OTA), oder es war absichtlich (verwenden Sie den native Weg oben).

Welche Flagge wird auf welches Job gesetzt?

Weg	Wann	Uploadflags
OTA	JS-nur; native Pakete entsprechen dem Kanal	--fail-on-incompatible + --auto-min-update-version wenn der Kanal aktiv ist metadata)
Native Basis	Neuer natives Binär + passende JS-Bundle	Nein --fail-on-incompatible; behalten --auto-min-update-version

Zugehörig

Native Kompatibilität

Wie Capgo natives Paketdrift erkennt und was unkompatibel bedeutet für Geräte.

Auto OTA oder Native

Wire bundle releaseType in die GitHub Aktionen oder GitLab, damit CI den richtigen Weg wählt.

Version Targeting

Kanäle, semver-Regeln und die Metadatenstrategie für Lieferflächen.

CLI: Paket

Referenz für Upload, Kompatibilität, releaseType und zugehörige Flags.

Weiter mit Native + OTA-Kanal-Workflow

Wenn Sie Live Updates verwenden Wenn Sie Native + OTA Kanalworkflow verwenden zum Schutz von Live-Updates über native Releases hinweg, verbinden Sie es mit Native Kompatibilität zur Vergleichsregel für Pakete Auto OTA oder Native zur CI-Branching Zielgruppenspezifische Versionierung Zielgruppenspezifische Versionierung Capgo CLI Paketbezugsreferenz __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ Paketbezug