Continuous Integration
Das Wonderland Editor Docker Image ermöglicht es, eine effiziente kontinuierliche Integration und Bereitstellung von Wonderland Engine-Projekten einzurichten.
Diese Seite beschreibt, wie man effiziente automatisierte Builds und Bereitstellungen mit den beliebtesten CI-Diensten einrichtet:
Zusätzlich wird beschrieben, wie man die Automatisierung für das Hochladen von Builds einrichtet:
Gitlab CI / Gitlab Pages
Unter Verwendung eines beliebigen Docker-Runners (z.B. der geteilten Runner von gitlab.com) auf Gitlab.
Konfiguration
Deine .gitlab-ci.yml sollte wie folgt aussehen:
1stages:
2 - build
3 - deploy
4
5package:
6 image: wonderlandengine/editor:latest
7 stage: build
8 script:
9 # Setze die WLE_CREDENTIALS-Variable, damit sich WonderlandEditor einloggen kann
10 - WonderlandEditor --windowless --package --project Project.wlp
11 cache:
12 key: ${CI_COMMIT_REF_SLUG}
13 paths:
14 - cache/
15 artifacts:
16 paths:
17 - deploy
18
19pages:
20 image: alpine:3.14
21 stage: deploy
22 rules:
23 # Nur auf der Haupt-/Master-Branch auf Pages bereitstellen
24 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
25 before_script:
26 - apk add gzip
27 script:
28 - gzip -k deploy/*.*
29 - mv deploy public
30 artifacts:
31 paths:
32 - public$WLE_CREDENTIALS ist eine Variable, die ein Zugangstoken enthält. Wir werden es im nächsten
Schritt konfigurieren.
Variablen
Finde Variablen für Gitlab CI in der Gitlab-Weboberfläche: Einstellungen > CI/CD > Variablen.
Klicke auf “Variable hinzufügen” und nenne sie WLE_CREDENTIALS. Der Wert sollte ein API-Token sein, das
du auf der Kontoseite unter “API-Token” abrufen kannst.
Fülle den Namen und das Ablaufdatum aus und klicke auf “Neues API-Token erstellen”. Das Token kann
aus dem neu erstellten Eintrag oben in der Liste kopiert werden.
Für öffentliche Projekte stelle sicher, dass du “Variable schützen” aktivierst, um zu verhindern, dass nicht fusionierte Merge Requests auf die CI-Variable zugreifen können.
Cache
Die zeitaufwändigste Aufgabe im Editor ist das Komprimieren von Texturen. Dies ist erheblich schneller, wenn die Ergebnisse zwischengespeichert werden (im Cache-Verzeichnis). Es ist daher nützlich, dieses Verzeichnis für den CI-Cache anzugeben oder die Dateien in die Quellkontrolle einzuchecken.
GitHub Workflows / GitHub Pages
Unter Verwendung eines beliebigen Docker-fähigen Runners (z.B. der von GitHub gehosteten Runner) auf GitHub.
Konfiguration
Deine Workflow-Datei (z.B. .github/workflows/github-pages.yml) sollte wie folgt aussehen:
1on: [push]
2
3permissions:
4 contents: read
5 pages: write
6 id-token: write
7
8jobs:
9 package:
10 runs-on: ubuntu-latest
11 container:
12 image: wonderlandengine/editor:latest
13 steps:
14 - name: Git installieren
15 run: apt-get update && apt-get install -y git git-lfs
16 - uses: actions/checkout@v4
17 with:
18 lfs: true
19 - name: Packen
20 run: /usr/local/bin/entrypoint.sh WonderlandEditor --windowless --package --project Project.wlp --output ./public/
21 env:
22 WLE_CREDENTIALS: ${{ secrets.WLE_CREDENTIALS }}
23 - name: Gzip
24 run: find ./public/ -type f ! -name '*.gz' -exec gzip -k "{}" \;
25 - name: Artefakt hochladen
26 uses: actions/upload-pages-artifact@v3
27 with:
28 path: ./public
29
30 deploy-pages:
31 needs: package
32 runs-on: ubuntu-latest
33 if: ${{ format('refs/heads/{0}', github.event.repository.default_branch) == github.ref }}
34 steps:
35 - name: Auf GitHub Pages bereitstellen
36 uses: actions/deploy-pages@v4Project.wlp ist deine Projektdatei.
$WLE_CREDENTIALS ist ein Geheimnis, das email:password enthält. Wir werden es im nächsten
Schritt konfigurieren.
Der deploy-pages Job wird nur auf dem Standardzweig deines
Repositories ausgeführt (normalerweise main).
Geheimnisse
Finde Geheimnisse für GitHub Workflows in der GitHub-Weboberfläche: Einstellungen > Geheimnisse > Aktionen.
Klicke oben rechts auf “Neues Repository-Geheimnis” und nenne es WLE_CREDENTIALS.
Der Wert sollte ein API-Token sein, das du auf der Kontoseite unter “API-Token” abrufen kannst.
Fülle den Namen und das Ablaufdatum aus und klicke auf “Neues API-Token erstellen”. Das Token kann
aus dem neu erstellten Eintrag oben in der Liste kopiert werden.
Geheimnisse werden nicht an Pull Requests von Forks weitergegeben, was bedeutet, dass dein Workflow möglicherweise nicht für Pull Requests von externen Mitarbeitern ausgeführt wird.
Bitbucket CI
Unter Verwendung eines beliebigen Docker-fähigen Runners (z.B. der von GitHub gehosteten Runner) auf GitHub.
Konfiguration
Deine Pipelines-Datei (z.B. bitbucket-pipelines.yml) sollte wie folgt aussehen:
Project.wlp ist deine Projektdatei.
$WLE_CREDENTIALS ist ein Geheimnis, das email:password enthält. Wir werden es im nächsten
Schritt konfigurieren.
Beachte, dass Bitbucket derzeit keinen Dienst zum Hosting von statischen Seiten wie Gitlab Pages oder GitHub Pages anbietet. Stattdessen kannst du dies mit der Bereitstellung auf Netlify kombinieren.
Deploy to Netlify
Hier verwenden wir das Netlify CLI, um die “kontinuierliche Bereitstellung” vorzunehmen.
Konfiguration
Konfiguriere .gitlab-ci.yml wie im Abschnitt Gitlab CI beschrieben.
Füge das Deployment zu den Stufen hinzu:
Füge dann den folgenden Deploy-Job am Ende der Datei hinzu:
Variablen
Finde Variablen für Gitlab CI in der Gitlab-Weboberfläche: Einstellungen > CI/CD > Variablen.
Füge eine Variable mit dem Schlüssel NETLIFY_AUTH_TOKEN hinzu und setze ihren Wert auf den Netlify-Zugangstoken. Du kannst ihn hier erstellen.
Füge ebenfalls eine weitere Variable mit dem Schlüssel NETLIFY_SITE_ID hinzu. Setze ihren Wert auf die “Site ID” der Seite, die du bereitstellen möchtest. Dies findest du unter
Site-Einstellungen > Allgemein > Site-Details > Site-Informationen.
(Falls du noch keine Seite erstellt hast, folge der Anleitung
hier).
Publish to HeyVR
Um von CI aus auf HeyVR zu veröffentlichen, kannst du das inoffizielle “heyvr-cli” Paket auf npm verwenden.
Der finale Veröffentlichungsschritt muss im HeyVR-Entwicklerportal erfolgen.
Authentifizierung
Rufe einen API-Schlüssel in deinen HeyVR-Kontoeinstellungen unter “Developer Access Token” ab.
Füge eine CI-Variable oder ein Geheimnis HEYVR_ACCESS_TOKEN mit dem Token als Wert hinzu.
Für GitHub Workflows musst du das Token zur Umgebung hinzufügen:
Builds hochladen
Wenn du Builds von CI aus hochlädst, stelle sicher, dass das Projekt ins
deploy/ Verzeichnis gepackt ist und füge den folgenden Befehl zu deinem CI-Skript hinzu:
Die “heyvr-game-id” ist der Slug von dem Spiel, das du auf HeyVR erstellt hast.
Für GitHub Actions, ersetze $CI_COMMIT_TAG mit
${{ github.ref_name }}.
Publish to Itch.io
Itch.io bietet ein CLI-Tool namens “butler” zum Hochladen von Builds auf deine Spielseiten.
Authentifizierung
Um die Veröffentlichung für Gitlab CI oder GitHub Workflows zu automatisieren, musst du einen API-Schlüssel abrufen, indem du folgenden Befehl ausführst:
1butler loginDer Befehl gibt den Pfad zur Datei aus, in die er den API-Schlüssel geschrieben hat. Kopiere
die Inhalte und füge eine CI-Variable oder ein Geheimnis namens BUTLER_API_KEY hinzu.
Siehe die Itch.io-Dokumentationsseite für weitere Informationen.
Butler installieren
Um den butler Befehl in deinem CI-Job verfügbar zu haben, kannst du ein
Docker-Image verwenden, das Butler vorinstalliert hat:
1 image: dosowisko/butlerHier verwenden wir dosowisko/butler, aber es gibt viele Alternativen.
Builds hochladen
Wenn du Builds von CI aus hochlädst, stelle sicher, dass das Projekt ins
deploy/ Verzeichnis gepackt ist und füge den folgenden Befehl zu deinem CI-Skript hinzu:
1 - butler push ./deploy user/game:channel-nameSiehe die Itch.io-Dokumentationsseite für weitere Informationen.
Explizite Version
Du kannst auch eine explizite Versionsnummer beim Bereitstellen von Tags anhängen.
Für Gitlab CI verwende --userversion $CI_COMMIT_TAG und für GitHub Actions
verwende --userversion ${{ github.ref_name }}.