Integración Continua
La imagen de Docker del Editor de Wonderland permite configurar una integración y entrega continua eficiente para los proyectos de Wonderland Engine.
Esta página describe cómo configurar construcciones automáticas eficientes y el despliegue con los servicios de CI más populares:
Además, esta página explica cómo automatizar la carga de construcciones a:
Gitlab CI / Gitlab Pages
Utilizando cualquier runner de Docker (por ejemplo, los runners compartidos de gitlab.com) en Gitlab.
Configuración
Tu archivo .gitlab-ci.yml
debería verse así:
1stages:
2 - build
3 - deploy
4
5package:
6 image: wonderlandengine/editor:latest
7 stage: build
8 script:
9 # Configurar la variable WLE_CREDENTIALS para que WonderlandEditor inicie sesión
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 # Solo desplegar a pages en la rama principal
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
es una variable que contiene un token de acceso. Lo configuraremos en el siguiente paso.
Variables
Encuentra variables para Gitlab CI en la interfaz web de Gitlab: Configuración > CI/CD > Variables.
Haz clic en “Agregar Variable” y nómbrala WLE_CREDENTIALS
. Su valor debe ser un API-Token, que puedes obtener en la página de cuenta, bajo “API-Token”. Completa el nombre y la fecha de expiración, luego haz clic en “Crear Nuevo API-Token”. Puedes copiar el token de la nueva entrada creada en la parte superior de la lista.
Para proyectos públicos, asegúrate de habilitar “Proteger variable” para evitar que solicitudes de fusión no unidas puedan acceder a la variable de CI.
Caché
La tarea que consume más tiempo en el editor es la compresión de texturas. Esto es significativamente más rápido si los resultados se guardan en caché (en el directorio cache/). Por lo tanto, es útil especificar esta carpeta para la caché de CI o registrar los archivos en el control de versiones.
GitHub Workflows / GitHub Pages
Usando cualquier runner habilitado para Docker (por ejemplo, los runners alojados por GitHub) en GitHub.
Configuración
Tu archivo de flujo de trabajo (por ejemplo, .github/workflows/github-pages.yml
) debería verse de la siguiente manera:
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: Install Git
15 run: apt-get update && apt-get install -y git git-lfs
16 - uses: actions/checkout@v4
17 with:
18 lfs: true
19 - name: Package
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: Upload artifact
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: Deploy to GitHub Pages
36 uses: actions/deploy-pages@v4
Project.wlp
es tu archivo de proyecto.
$WLE_CREDENTIALS
es un secreto que contiene email:password
. Lo configuraremos en el siguiente paso.
El trabajo deploy-pages
solo se ejecutará en la rama predeterminada de tu repositorio (generalmente main
).
Secretos
Encuentra secretos para GitHub Workflows en la interfaz web de GitHub: Configuración > Secretos > Acciones.
Haz clic en “Nuevo secreto de repositorio” en la parte superior derecha y nómbralo WLE_CREDENTIALS
. Su valor debe ser un API-Token, que puedes obtener en la página de cuenta, bajo “API-Token”. Completa el nombre y la fecha de expiración, luego haz clic en “Crear Nuevo API-Token”. Puedes copiar el token de la nueva entrada creada en la parte superior de la lista.
Los secretos no se pasan a pull requests desde forks, lo que significa que tu flujo de trabajo puede no ejecutarse para pull requests de colaboradores externos.
Bitbucket CI
Utilizando cualquier runner habilitado para Docker (por ejemplo, los runners alojados por GitHub) en GitHub.
Configuración
Tu archivo de pipelines (por ejemplo, bitbucket-pipelines.yml
) debería verse así:
Project.wlp
es tu archivo de proyecto.
$WLE_CREDENTIALS
es un secreto que contiene email:password
. Lo configuraremos en el siguiente paso.
Ten en cuenta que Bitbucket actualmente no ofrece un servicio para alojar páginas estáticas como Gitlab Pages o GitHub Pages. En su lugar, puedes combinar esto con deploy to netlify.
Desplegar en Netlify
Aquí estamos usando Netlify CLI para el “despliegue continuo”.
Configuración
Configura .gitlab-ci.yml
como se describe en Gitlab CI.
Añade despliegue a las etapas:
Luego añade el siguiente trabajo de despliegue al final del archivo:
Variables
Encuentra variables para Gitlab CI en la interfaz web de Gitlab: Configuración > CI/CD > Variables.
Añade una variable con una clave NETLIFY_AUTH_TOKEN
y establece su valor al token de acceso de Netlify. Puedes crear uno aquí.
De manera similar, añade otra variable con una clave NETLIFY_SITE_ID
. Establece su valor al “ID del Sitio” del sitio que deseas desplegar. Esto se encuentra en configuración del sitio > General > Detalles del sitio > Información del sitio
. (En caso de que no hayas creado un sitio, sigue la guía aquí).
Publicar en HeyVR
Para publicar desde CI a HeyVR puedes usar el paquete no oficial “heyvr-cli” en npm.
El paso final de publicación debe realizarse en el portal de desarrolladores de HeyVR.
Autenticación
Obtén una clave API en tus Configuraciones de Cuenta de HeyVR bajo “Token de Acceso para Desarrolladores”.
Añade una variable de CI o secreto HEYVR_ACCESS_TOKEN
con el token como valor.
Para GitHub Workflows, necesitas agregar el token al entorno:
Enviar Construcciones
Cuando envíes construcciones desde CI, asegúrate de que el proyecto esté empaquetado en la carpeta deploy/
y añade el siguiente comando a tu script de CI:
El “heyvr-game-id” es el slug del juego que creaste en HeyVR.
Para GitHub Actions, reemplaza $CI_COMMIT_TAG
con ${{ github.ref_name }}
.
Publicar en Itch.io
Itch.io proporciona una herramienta CLI llamada “butler” para subir construcciones a tus páginas de juego.
Autenticación
Para automatizar la publicación en Gitlab CI o GitHub Workflows, necesitarás obtener una clave API ejecutando:
1butler login
El comando imprimirá la ruta al archivo donde escribió la clave API. Copia el contenido y añade una variable de CI o secreto llamado BUTLER_API_KEY
.
Consulta la página de documentación de Itch.io para más información.
Instalación de Butler
Para tener el comando butler
disponible en tu trabajo de CI, puedes usar una imagen de Docker que venga con Butler preinstalado:
1 image: dosowisko/butler
Aquí usamos dosowisko/butler, pero hay muchas alternativas.
Enviar Construcciones
Cuando envíes construcciones desde CI, asegúrate de que el proyecto esté empaquetado en la carpeta deploy/
y añade el siguiente comando a tu script de CI:
1 - butler push ./deploy user/game:channel-name
Consulta la página de documentación de Itch.io.
Versión Explícita
También puedes agregar un número de versión explícito al desplegar desde etiquetas. Para Gitlab CI, usa --userversion $CI_COMMIT_TAG
y para GitHub Actions usa --userversion ${{ github.ref_name }}
.