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í:

stages:
  - build
  - deploy

package:
  image: wonderlandengine/editor:latest
  stage: build
  script:
    # Configurar la variable WLE_CREDENTIALS para que WonderlandEditor inicie sesión
    - WonderlandEditor --windowless --package --project Project.wlp
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - cache/
  artifacts:
    paths:
      - deploy

pages:
  image: alpine:3.14
  stage: deploy
  rules:
    # Solo desplegar a pages en la rama principal
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  before_script:
    - apk add gzip
  script:
    - gzip -k deploy/*.*
    - mv deploy public
  artifacts:
    paths:
      - 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:

on: [push]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  package:
    runs-on: ubuntu-latest
    container:
      image: wonderlandengine/editor:latest
    steps:
    - name: Install Git
      run: apt-get update && apt-get install -y git git-lfs
    - uses: actions/checkout@v4
      with:
        lfs: true
    - name: Package
      run: /usr/local/bin/entrypoint.sh WonderlandEditor --windowless --package --project Project.wlp --output ./public/
      env:
          WLE_CREDENTIALS: ${{ secrets.WLE_CREDENTIALS }}
    - name: Gzip
      run: find ./public/ -type f ! -name '*.gz' -exec gzip -k "{}" \;
    - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public

  deploy-pages:
    needs: package
    runs-on: ubuntu-latest
    if: ${{ format('refs/heads/{0}', github.event.repository.default_branch) == github.ref }}
    steps:
      - name: Deploy to GitHub Pages
        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í:

image: wonderlandengine/editor:latest

pipelines:
  default:
    - step:
        name: 'Construcción'
        script:
          - /usr/local/bin/entrypoint.sh WonderlandEditor --windowless --package --project Project.wlp
        artifacts:
          - deploy/**

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:

stages:
  - build
  - deploy

Luego añade el siguiente trabajo de despliegue al final del archivo:

netlify:
  image: node:15
  stage: deploy
  script:
    - npm install -g netlify-cli
    - netlify deploy --dir=public --prod

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:

  env:
    HEYVR_ACCESS_TOKEN: ${{ secrets.HEYVR_ACCESS_TOKEN }}

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:

  - npm i -g heyvr-cli
  - heyvr --version $CI_COMMIT_TAG --gameId "heyvr-game-id"

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:

butler 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:

    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:

  - 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 }}.

Source Control