Orbit
Build-Logs anzeigen
Every Orbit deployment keeps its complete build log, plus a structured breakdown of what the build did and how long each phase took. This guide covers where to find the log, how to read the…
Das Anzeigen des Protokolls für die neueste Bereitstellung
Öffnen Sie das Projekt in Orbit. Das Panel Latest build auf der Registerkarte Overview zeigt das Protokoll der letzten Bereitstellung. Wenn gerade ein Build läuft, wird das Protokoll live gestreamt, Zeile für Zeile, wie der Build-Agent es erzeugt.
Klicken Sie auf Full details, um die vollständige Seite mit Bereitstellungsdetails zu öffnen.
Anzeigen von Protokollen für eine bestimmte Bereitstellung
- Öffnen Sie Ihr Projekt in Orbit.
- Öffnen Sie die Registerkarte Deployments.
- Klicken Sie auf eine beliebige Bereitstellung, um die zugehörige Detailseite zu öffnen.
- Das vollständige Build-Protokoll ist auf dieser Seite.
Die Liste Recent deployments auf der Registerkarte „Overview" hat einen Link View logs in jeder Zeile, der zum gleichen Ort führt. Preview-Bereitstellungen haben den gleichen Link im Abschnitt Preview deployments.
Build-Phasen
Die Detailseite teilt den Build in benannte Phasen mit einer Dauer für jede Phase auf:
| Phase | Was geschieht |
|---|---|
| Clone | Abrufen des Repositorys beim bereitgestellten Commit |
| Cache restore | Entpacken des zwischengespeicherten node_modules, bei Plänen mit Build-Cache |
| Install | Ausführen des Installationsbefehls |
| Cache save | Neuverpacken von node_modules für den nächsten Build |
| Build | Ausführung des Build-Befehls |
| Upload | Verpacken des Ausgabeverzeichnisses und Speichern des Artefakts |
| Done | Das Artefakt ist vor dem Traffic |
Dies ist der schnellste Weg, um zu beantworten: „Warum war dieser Build so langsam". Eine lange Install-Phase mit einem Cold build-Badge bedeutet, dass der Cache verfehlt wurde. Eine lange Build-Phase bedeutet, dass Ihr eigener Build langsamer geworden ist.
Build-Metadaten
Die Karten über dem Protokoll zeigen die Fakten zur Bereitstellung:
| Karte | Was wird angezeigt |
|---|---|
| Status | Queued, Building, Deploying, Succeeded, Failed, Cancelled, Rolled back oder Awaiting approval |
| Commit | Der Commit, den diese Bereitstellung erstellt hat, mit Link zum Provider |
| Branch | Der Git-Branch, von dem er stammt |
| Author | Wer den Commit gepusht hat |
| Build time | Gesamtwall-Clock-Zeit, mit einer Fast-, Normal- oder Slow-Bewertung gegenüber Ihrer eigenen Historie |
| Artifact | Verpackte Ausgabegröße, mit einem Download-Link |
| Framework | Das Framework, das Orbit erkannt hat |
| Package manager | npm, yarn oder pnpm, erkannt aus Ihrer Lockfile |
| Build cache | Cache hit oder Cold build |
| Build host | Welcher Build-Host es ausgeführt hat |
| Queue position | Ihre Position in der Warteschlange, während die Bereitstellung noch in der Warteschlange ist |
| Pull request | Die PR-Nummer für eine Preview-Bereitstellung |
| Health score | Eine Punktzahl von 100 mit den aufgelisteten Abzügen |
Analyse, die Orbit über das Protokoll ausführt
Die Detailseite ist keine einfache Textausgabe. Orbit analysiert das Protokoll und zeigt das Wichtigste an.
- Build-Zeitleiste mit Dauern pro Phase.
- Slow build detected, wenn ein Build deutlich langsamer ist als Ihr eigener Medianwert, mit dem Prozentsatz und Ihrer typischen Zeit aus den letzten 10 Builds.
- TypeScript errors, extrahiert und gezählt, wenn der Build bei der Typprüfung fehlgeschlagen ist.
- Build analysis für Next.js-Builds: Pro-Route-Größen, First-Load-JS und statische, dynamische und ISR-Route-Zählungen.
- Bundle regression-Warnungen, wenn das First-Load-JS einer Route um mehr als 20% gegenüber der vorherigen Bereitstellung wächst oder das gemeinsame JS-Bundle wächst.
- npm audit-Ergebnisse, direkt aus der Install-Ausgabe analysiert, zusammengefasst nach Schweregrad.
- Security headers audit, bewertet mit bis zu 60 Punkten.
- Smoke test-Ergebnisse, falls Sie Smoke-Test-Pfade konfiguriert haben.
- Performance budgets, überschritten, falls Sie Budgets festgelegt haben.
- Build optimization advisor, das konkrete Änderungen mit geschätzter Größeneinsparung auflistet, nach Auswirkung sortiert.
- Real user metrics, die p75 Core Web Vitals, die während dieser Bereitstellung live waren.
Welche Umgebungsvariablen der Build tatsächlich sah
Die Detailseite listet die Schlüssel der Umgebungsvariablen auf, die zur Build-Zeit eingefügt wurden, und unterscheidet sie von Ihrer aktuellen Konfiguration: hinzugefügt, geändert, entfernt, unverändert. Farbige Schlüssel stammten aus einer umgebungsspezifischen Außerkraftsetzung, graue aus der Projektebene.
Werte werden nie gespeichert und nie angezeigt. Mit dem Mauszeiger über einen Schlüssel erhalten Sie einen SHA-256-Fingerabdruck, der ausreicht, um zu bestätigen, dass zwei Umgebungen den gleichen Wert haben, ohne ihn preiszugeben.
Dieser Unterschied ist der schnellste Weg, um zu beantworten: „Hat meine Änderung der Umgebungsvariable tatsächlich in den Build geschafft". Wenn die Bereitstellung der Änderung vorausgeht, teilt Orbit dies mit einer Environment variables updated since this deployment-Benachrichtigung mit und erinnert Sie daran, dass die Änderung erst nach einer erneuten Bereitstellung wirksam wird.
Vergleichen von zwei Bereitstellungen
Klicken Sie auf Compare bei einer Bereitstellung, um sie mit der vorherigen zu vergleichen: Build-Zeit, Artefaktgröße, Cache-Status, Framework und der Artefaktunterschied auf Dateiebene. Dies ist die schnellste Route zu „Was hat sich tatsächlich geändert", wenn sich eine Bereitstellung anders verhält als die vorherige.
Wenn ein Build fehlschlägt
Die Statuskarte wird auf „Failed" umgeschaltet und das Protokoll zeigt, wo es angehalten hat. Über dem Protokoll fügt Orbit eine kategorisierte Fehlerzusammenfassung mit einem vorgeschlagenen Fix hinzu. Erkannte Kategorien sind Speichermangel, Compilerfehler, Testfehler, Lint-Fehler, Installationsfehler, Netzwerkfehler und Timeout. Orbit gleicht spezifische Muster ab, z. B. ein fehlender Modul, ein ERESOLVE Peer-Dependency-Konflikt, ein TypeScript-Fehlercode, eine volle Build-Festplatte, eine Paket-404 und eine veraltete Lockfile.
Es gibt auch einen Get AI diagnosis-Button, der die letzten 120 Zeilen des Protokolls zusammen mit dem erkannten Framework und der Fehlerkategorie liest und eine Erklärung in Klartext zurückgibt.
Die KI-Diagnose ist mit AI-generated, verify before acting gekennzeichnet. Sie ist sehr gut darin, Sie auf die richtige Zeile des Protokolls hinzuweisen, und sie ist nicht bindend für Ihre Codebasis. Lesen Sie die Protokollzeile, auf die sie verweist, bevor Sie etwas ändern.
Erneutes Versuchen eines fehlgeschlagenen Builds
Klicken Sie auf der Seite „Deployment detail" auf Retry build, um den gleichen Commit erneut auszuführen, ohne einen neuen zu pushen. Dies behebt vorübergehende Fehler wie einen Netzwerkfehler während der Installation.
Wenn Sie einen veralteten Cache-abhängigen vermuten, verwenden Sie More retry options und dann Retry with cleared cache, was den Build-Cache vor dem erneuten Versuch löscht.
Vollständige Hinweise für jeden Fehler finden Sie unter Fehlgeschlagene Builds beheben.
Abbrechen eines laufenden Builds
Klicken Sie auf Cancel, während ein Build läuft.
Das Abbrechen beendet die Build-Maschine sofort und kann nicht rückgängig gemacht werden. Die Bereitstellung wird als Cancelled aufgezeichnet, und die zuvor live Bereitstellung wird weiterhin Traffic serviert. Das Abbrechen bringt Ihre Website also nie herunter. Beachten Sie, dass das Pushen eines neuen Commits zum gleichen Branch, während ein Build läuft, den laufenden Build automatisch abbricht. Eine abgebrochene Bereitstellung gefolgt von einer laufenden ist also normal.
Herunterladen des Artefakts
Jede erfolgreiche Bereitstellung behält ihre verpackte Ausgabe. Klicken Sie auf Download auf der Artifact-Karte, um das genaue Bundle zu ziehen, das serviert wurde. Es gibt auch einen Artifact-Browser zum Inspizieren des Inhalts, ohne das Ganze herunterzuladen.
Wie lange Artefakte aufbewahrt werden, wird in Settings unter Artifact retention festgelegt: die Anzahl der erfolgreichen Artefakte, die pro Umgebung aufbewahrt werden sollen, von 10 bis 500, standardmäßig 50. Ältere Artefakte werden täglich gelöscht. Das Artefakt der derzeit live geschalteten Bereitstellung wird immer beibehalten, unabhängig von der Einstellung.
Die Artifact-Retention ist das, was Rollback möglich macht. Wenn Sie es zu niedrig einstellen, verkürzt sich, wie weit Sie zurück in eine schlechte Bereitstellung ohne Neubuild zurückrollen können. Wenn Sie viele Male am Tag bereitstellen, erhöhen Sie es lieber, als es zu senken.