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.

Wenn du Änderungen in dein Repository pushst, verwendet GitHub Codespaces standardmäßig GitHub Actions, um deine Prebuilds automatisch zu aktualisieren.

Wenn Prebuilds für einen spezifischen Branch eines Repositorys, eine spezifische Konfigurationsdatei für den Entwicklungscontainer und für deine Region verfügbar sind, wird in der Liste der Maschinentypoptionen die Bezeichnung „ Prebuild ready“ angezeigt, wenn du einen Codespace erstellst. Wenn sich ein Prebuild in der Erstellung befindet, wird das Label „ Prebuild in progress“ angezeigt. Weitere Informationen finden Sie unter AUTOTITLE.

Wenn du einen Codespace aus einer Vorlage auf der Seite „Deine Codespaces“ erstellst, kann GitHub automatisch einen Prebuild verwenden, um die Erstellungszeit zu beschleunigen. Weitere Informationen zu Vorlagen findest du unter AUTOTITLE.

Der Prebuildprozess

Zum Erstellen eines Prebuilds muss eine Prebuildkonfiguration eingerichtet werden. Wenn du die Konfiguration speicherst, wird ein GitHub Actions-Workflow ausgeführt, um jeden der erforderlichen Prebuilds zu erstellen: ein Workflow pro Prebuild. 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 AUTOTITLE.

Wenn ein vorkonfigurierter Build-Workflow ausgeführt wird, erstellt GitHub einen temporären Codespace und führt Setup-Vorgänge bis zu den Befehlen [setup] und [install] in der [config]-Datei aus. Während der Erstellung eines Prebuilds werden keine -Befehle ausgeführt. Weitere Informationen zu diesen Befehlen findest du in der -Referenz in der VS Code-Dokumentation. Eine Momentaufnahme des generierten Containers wird dann aufgezeichnet und gespeichert.

Genau wie bei anderen GitHub Actions-Workflows werden beim Ausführen eines Prebuildkonfigurationsworkflows entweder einige der in deinem Konto ggf. enthaltenen GitHub Actions-Minuten verbraucht, 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 AUTOTITLE.

Wenn du einen Codespace aus einem Prebuild erstellst, lädt GitHub den vorhandenen Container-Schnappschuss aus dem Speicher herunter und stellt ihn auf einer neuen virtuellen Maschine bereit, wobei die verbleibenden in der Dev-Container-Konfiguration angegebenen Befehle ausgeführt werden. 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 -Befehlen lange dauert.

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

Jeder Push in einen Branch mit einer Prebuildkonfiguration führt standardmäßig zur Ausführung eines von GitHub verwalteten GitHub Actions-Workflows, um den 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 AUTOTITLE. 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 Pushes auf einen Branch durchgeführt werden, der eine Prebuild-Konfiguration 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.