Informationen zu GitHub Codespaces-Vorkompilierungen

Übersicht

Ein Prebuild stellt die Hauptkomponenten eines Codespace für eine bestimmte Kombination aus Repository, Branch und devcontainer.json-Konfigurationsdatei zusammen. Dies ist eine schnelle Möglichkeit zum Erstellen eines neuen Codespace. Insbesondere bei komplexen und/oder umfangreichen Repositorys kannst du mit einem Prebuild schneller einen neuen Codespace erstellen.

Wenn es derzeit mehr als 2 Minuten dauert, einen Codespace für ein Repository zu erstellen, profitierst du wahrscheinlich von der Verwendung von Prebuilds. Dies liegt daran, dass bei Verwendung von Prebuilds sämtlicher Quellcode, alle Editorerweiterungen, Projektabhängigkeiten, Befehle und Konfigurationen bereits heruntergeladen, installiert und angewendet wurden, bevor du einen Codespace erstellst.

Standardmäßig verwendet GitHub Codespaces bei jeder Übertragung von Änderungen in Ihr Repository GitHub Actions, um Ihre Prebuilds automatisch zu aktualisieren.

Wenn Prebuilds für eine bestimmte Verzweigung eines Repositorys, eine bestimmte Entwicklungscontainerkonfigurationsdatei und für Ihre Region verfügbar sind, wird die Bezeichnung " Prebuild ready" in der Liste der Computertypoptionen angezeigt, wenn Sie einen Codespace erstellen. Wenn noch ein Vorabbuild erstellt wird, wird die Bezeichnung " Prebuild in Bearbeitung" angezeigt. Weitere Informationen finden Sie unter Erstellen eines Codespaces für ein Repository.

Wenn Sie auf der Seite „Ihre Codespaces“ einen Codespace aus einer Vorlage erstellen, kann GitHub möglicherweise automatisch einen Vorabbuild verwenden, um die Erstellungszeit zu verkürzen. Weitere Informationen zu Vorlagen findest du unter Erstellen eines Codespaces aus einer Vorlage.

Der Prebuildprozess

Zum Erstellen eines Prebuilds muss eine Prebuildkonfiguration eingerichtet werden. Wenn Sie die Konfiguration speichern, wird ein GitHub Actions Workflow ausgeführt, um jeden der erforderlichen Vorbuilds zu erstellen. Ein Workflow pro Vorbuild. Workflows werden auch ausgeführt, wenn die Prebuilds für deine Konfiguration aktualisiert werden müssen. Dies kann in geplanten Abständen erfolgen, bei Pushs in ein Repository mit Prebuildunterstützung oder wenn du die Dev-Containerkonfiguration änderst. Weitere Informationen finden Sie unter Konfigurieren von Prebuilds.

Wenn ein Prebuild-Konfigurationsworkflow ausgeführt wird, erstellt GitHub einen temporären Codespace und führt Einrichtungsschritte bis zu den in der Datei devcontainer.json enthaltenen onCreateCommand- und updateContentCommand-Befehlen einschließlich aus. Während der Erstellung eines Prebuilds werden keine postCreateCommand-Befehle ausgeführt. Weitere Informationen zu diesen Befehlen finden Sie in der devcontainer.json Referenz in der VS Code Dokumentation. Eine Momentaufnahme des generierten Containers wird dann aufgezeichnet und gespeichert.

Wie bei anderen GitHub Actions-Workflows verbraucht das Ausführen eines Workflows für die Prebuild-Konfiguration entweder einige der in Ihrem Konto enthaltenen GitHub Actions-Minuten, sofern vorhanden, oder es fallen Gebühren für GitHub Actions-Minuten an. Die Speicherung von Codespace-Prebuilds wird auf die gleiche Weise abgerechnet wie die Speicherung von aktiven oder beendeten Codespaces. Weitere Informationen finden Sie unter GitHub Codespaces Abrechnung.

Wenn Sie einen Codespace aus einem Prebuild erstellen, lädt GitHub den vorhandenen Container-Snapshot aus dem Speicher herunter, stellt ihn auf einer neuen virtuellen Maschine bereit und führt die verbleibenden in der Dev-Container-Konfiguration angegebenen Befehle aus. Da viele Vorgänge bereits ausgeführt wurden, z. B. das Klonen des Repositorys, kann das Erstellen eines Codespaces aus einem Prebuild erheblich schneller gehen als ohne Prebuild. Dies gilt, wenn das Repository groß ist und/oder die Ausführung von onCreateCommand-Befehlen lange dauert.

Informationen zum Pushen von Änderungen an Branches mit Prebuildunterstützung

Standardmäßig führt jeder Push in einen Branch mit einer Prebuild-Konfiguration zu einem von GitHub verwalteten GitHub Actions-Workflowlauf, um das Prebuild zu aktualisieren. Für den Prebuildworkflow gilt, dass parallel zur Ausführung eines Workflows für eine bestimmte Prebuildkonfiguration keine weitere Ausführung stattfinden kann, sofern keine Änderungen vorgenommen wurden, die sich auf die Entwicklungscontainerkonfiguration für das zugehörige Repository auswirken. Weitere Informationen finden Sie unter Einführung in Dev-Container. Wenn bereits eine Ausführung durchgeführt wird, wird die zuletzt in die Warteschlange eingereihte Workflowausführung nach Abschluss der aktuellen Ausführung gestartet.

Wenn du den Prebuild so festlegst, dass er bei jedem Push aktualisiert wird, bedeutet das, dass bei sehr häufigen Pushes in dein Repositorys der Prebuild mindestens so oft aktualisiert wird, wie es dauert, den Prebuildworkflow auszuführen. Das heißt, wenn deine Workflowausführung in der Regel eine Stunde dauert, werden Prebuilds für dein Repository ungefähr stündlich erstellt, falls die Ausführung erfolgreich ist, oder häufiger, wenn Pushes erfolgt sind, die die Konfiguration des Entwicklungscontainers im Branch geändert haben.

Stellen wir uns beispielsweise vor, dass in schneller Folge 5 Pushs auf einen Branch durchgeführt werden, der eine Prebuildkonfiguration aufweist. In dieser Situation gilt:

• Eine Workflowausführung wird für den ersten Push gestartet, um den Prebuild zu aktualisieren.

• Wenn die 4 verbleibenden Pushs keine Auswirkungen auf die Entwicklungscontainerkonfiguration haben, werden die Workflowausführungen für diese in einem „ausstehenden“ Zustand in die Warteschlange gestellt.

  Wenn einer der restlichen 4 Pushs die Entwicklungscontainerkonfiguration ändert, wird der Dienst diesen nicht überspringen, und wird sofort den Prebuilderstellungsworkflow ausführen und bei erfolgreicher Ausführung den Prebuild entsprechend aktualisieren.

• Sobald die erste Ausführung abgeschlossen ist, werden die Workflowausführungen für Push 2, 3 und 4 abgebrochen, und der letzte Workflow in der Warteschlange (für Push 5) führt den Prebuild aus und aktualisiert ihn.