継続的インテグレーション

Wonderland Editor Docker Imageを使用すると、Wonderland Engineプロジェクトの効率的な継続的インテグレーションとデリバリーを設定できます。

このページでは、以下の最も人気のあるCIサービスで効率的な自動ビルドとデプロイを設定する方法を説明します:

さらに、このページではビルドを自動でアップロードする方法を説明します:

Gitlab CI / Gitlab Pages 

任意のdockerランナー（例: gitlab.comの共有ランナー）をGitlabで使用します。

設定 

.gitlab-ci.ymlは以下のようになります:

stages:
  - build
  - deploy

package:
  image: wonderlandengine/editor:latest
  stage: build
  script:
    # WonderlandEditorがログインするためのWLE_CREDENTIALS変数を設定
    - 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:
    # main/masterブランチのみにデプロイ
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  before_script:
    - apk add gzip
  script:
    - gzip -k deploy/*.*
    - mv deploy public
  artifacts:
    paths:
      - public

$WLE_CREDENTIALSはアクセストークンを含む変数です。次のステップで設定します。

変数 

Gitlab CI用の変数はGitlabのウェブインターフェイスで見つかります: Settings > CI/CD > Variables。

「Add Variable」をクリックし、名前をWLE_CREDENTIALSに設定します。その値はAPIトークンで、アカウントページの「API-Token」で取得できます。 名前と有効期限を入力し、「Create New API-Token」をクリックします。トークンはリストの一番上の新しく作成されたエントリからコピーできます。

公開プロジェクトのための「Protect variable」を有効にして、マージされていないマージリクエストがCI変数にアクセスできないようにしてください。

キャッシュ 

最も時間がかかるタスクはテクスチャの圧縮です。キャッシュ（cache/ディレクトリに）すると大幅に高速化されます。したがって、このフォルダをCIキャッシュに指定するか、ソース管理にファイルをチェックインすることが有用です。

GitHub Workflows / GitHub Pages 

任意のdocker対応ランナー（例: GitHubのホストランナー）をGitHubで使用します。

設定 

ワークフローファイル（例: .github/workflows/github-pages.yml）は以下のようになります:

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はプロジェクトファイルです。

$WLE_CREDENTIALSはemail:passwordを含むシークレットです。次のステップで設定します。

deploy-pagesジョブはリポジトリのデフォルトブランチ（通常main）でのみ実行されます。

シークレット 

GitHub Workflows用のシークレットはGitHubのウェブインターフェイスで見つかります: Settings > Secrets > Actions。

画面右上の「New repository secret」をクリックし、名前をWLE_CREDENTIALSに設定します。 その値はAPI-Tokenで、アカウントページの「API-Token」で取得できます。 名前と有効期限を入力し、「Create New API-Token」をクリックします。トークンはリストの一番上の新しく作成されたエントリからコピーできます。

シークレットはフォークからのプルリクエストには渡されないため、外部の共同作業者からのプルリクエストではワークフローが実行されない可能性があります。

Bitbucket CI 

任意のdocker対応ランナー（例: GitHubのホストランナー）をGitHubで使用します。

設定 

パイプラインファイル（例: bitbucket-pipelines.yml）は以下のようになります:

image: wonderlandengine/editor:latest

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

Project.wlpはプロジェクトファイルです。

$WLE_CREDENTIALSはemail:passwordを含むシークレットです。次のステップで設定します。

Bitbucketは現在、Gitlab PagesやGitHub Pagesのような静的ページホスティングサービスを提供していません。 代わりに、これをネットリファイへのデプロイと組み合わせて使用できます。

デプロイ先: Netlify 

ここでは、Netlify CLIを使用して「継続デプロイ」を行います。

設定 

Gitlab CIで説明したように.gitlab-ci.ymlを設定します。

デプロイをステージに追加します:

stages:
  - build
  - deploy

次に、ファイルの最後に以下のデプロイジョブを追加します:

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

変数 

Gitlabのウェブインターフェイスで、Gitlab CI用の変数を見つけます: Settings > CI/CD > Variables。

キーとしてNETLIFY_AUTH_TOKENを持つ変数を追加し、その値をnetlifyのアクセス トークンに設定します。ここで作成できます：こちら。

同様に、NETLIFY_SITE_IDのキーを持つ別の変数を追加します。その値をデプロイサイトの 「Site ID」に設定します。これは、 site settings > General > Site details > Site informationで見つけられます。 （サイトをまだ作成していない場合は、ガイドを こちらに従ってください）。

HeyVRへの公開 

CIからHeyVRへ公開するには、非公式の “heyvr-cli”パッケージをnpmで使うことができます。

最終的な公開ステップはHeyVR開発者ポータルで行う必要があります。

認証 

HeyVR アカウント設定で、“Developer Access Token”の下からAPIキーを取得します。

トークンを値として持つCI変数またはシークレットHEYVR_ACCESS_TOKENを追加します。

GitHub Workflowsでは、トークンを環境に追加する必要があります:

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

ビルドのプッシュ 

CIからビルドをプッシュする際には、プロジェクトが deploy/フォルダにパッケージされていることを確認し、次のコマンドをCIスクリプトに追加してください:

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

“heyvr-game-id”は、heyvrで作成したゲームのスラグです。

GitHub Actionsの場合は、$CI_COMMIT_TAGを${{ github.ref_name }}に置き換えてください。

Itch.ioへの公開 

Itch.ioはCLIツール”butler” を提供しており、ビルドをゲームページにアップロードします。

認証 

Gitlab CIまたはGitHub Workflowsのための公開を自動化するには、 次のコマンドを実行してAPIキーを取得する必要があります:

butler login

このコマンドは、APIキーを書き込んだファイルのパスを出力します。 内容をコピーしてBUTLER_API_KEYという名前のCI変数またはシークレットに追加します。

詳しくはItch.io documentationページをご覧ください。

Butlerのインストール 

CIジョブでbutlerコマンドを利用可能にするには、 butlerが事前にインストールされたdockerイメージを使用できます:

    image: dosowisko/butler

ここではdosowisko/butlerを使用しますが、 多くの代替品があります。

ビルドのプッシュ 

CIからビルドをプッシュする際には、プロジェクトが deploy/フォルダにパッケージされていることを確認し、次のコマンドをCIスクリプトに追加してください:

  - butler push ./deploy user/game:channel-name

詳しくはItch.io documentationページをご覧ください。

明示的なバージョン 

タグからデプロイするときには、明示的なバージョン番号を追加することもできます。 Gitlab CIの場合は--userversion $CI_COMMIT_TAGを使用し、GitHub Actionsの場合は --userversion ${{ github.ref_name }}を使用してください。

Source Control