@leftibot what is the next steps for actually utilizing this on the website?

Good question. Right now the workflow builds the artifacts and uploads them via actions/upload-artifact, but there's no deployment step — the WASM build just sits as a downloadable zip on the Actions run. Here's what I'd suggest as next steps:

1. Decide on hosting strategy

A few options depending on where chaiscript.com is hosted:

• GitHub Pages (simplest): Add a deployment step to the workflow that publishes chaiscript.js, chaiscript.wasm, and chaiscript.html to a gh-pages branch or uses the actions/deploy-pages action. Could live at something like chaiscript.com/playground.
• Embed in existing site: If chaiscript.com is built separately (e.g., Jekyll, Hugo, or a custom site), the workflow could push the built artifacts to that site's repo or an S3 bucket / CDN as part of a release.
• Subdomain: Host at try.chaiscript.com or playground.chaiscript.com pointing to GitHub Pages on this repo.

2. Integrate with the site design

The current chaiscript.html is a standalone page. To integrate with the existing site you'd want to either:

• Embed it in the site's existing layout/navigation (header, footer, links)
• Or keep it standalone but link to it from the main site

3. Serve .wasm with correct MIME type

Whatever hosting you use needs to serve .wasm files with Content-Type: application/wasm. GitHub Pages does this correctly out of the box. If using another host, this may need configuration.

4. Trigger deployment on release (not every push)

The current workflow runs on every push/PR to develop/main. For the actual website deployment, you'd probably want to either:

• Deploy only from develop/main pushes (not PRs)
• Or tie deployment to tagged releases

5. Concrete next step

The smallest useful change would be adding a GitHub Pages deploy job to emscripten.yml. Something like:

  deploy:
    needs: emscripten
    if: github.ref == 'refs/heads/develop' && github.event_name == 'push'
    runs-on: ubuntu-latest
    permissions:
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: chaiscript-web
          path: site
      - uses: actions/configure-pages@v4
      - uses: actions/upload-pages-artifact@v4
        with:
          path: site
      - id: deployment
        uses: actions/deploy-pages@v4

That would get the playground live immediately. Want me to add a deployment job to the workflow?

@leftibot can it be deployed to https://github.com/ChaiScript/chaiscript.github.io directly with an action? The site is currently in a separate repo, not in the gh-pages branch

Yes, absolutely. You can push to ChaiScript/chaiscript.github.io from this repo's workflow using a deploy key or a PAT. Here's the approach:

Using a deploy key (recommended)

1. Generate an SSH keypair (ssh-keygen -t ed25519 -f deploy_key -N "")
2. Add the public key as a deploy key on ChaiScript/chaiscript.github.io with write access
3. Add the private key as a secret (e.g., DEPLOY_KEY) on ChaiScript/ChaiScript

Then add a deploy job to the workflow:

  deploy:
    needs: emscripten
    if: github.ref == 'refs/heads/develop' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: chaiscript-web
          path: artifacts

      - name: Clone target repo
        env:
          SSH_KEY: ${{ secrets.DEPLOY_KEY }}
        run: |
          mkdir -p ~/.ssh
          echo "$SSH_KEY" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          export GIT_SSH_COMMAND="ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no"
          git clone [email protected]:ChaiScript/chaiscript.github.io.git target

      - name: Copy artifacts and push
        run: |
          export GIT_SSH_COMMAND="ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no"
          # Copy into a subdirectory so it doesn't clobber the existing site
          mkdir -p target/playground
          cp artifacts/build-em/chaiscript.js target/playground/
          cp artifacts/build-em/chaiscript.wasm target/playground/
          cp artifacts/build-em/chaiscript.html target/playground/index.html
          cd target
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add playground/
          git diff --cached --quiet || git commit -m "Update ChaiScript playground from ChaiScript/ChaiScript@${GITHUB_SHA::8}"
          git push

This would make the playground available at chaiscript.com/playground (or whatever path the site uses) without interfering with the rest of the site content.

Alternative: PAT

A GitHub PAT with repo scope stored as a secret also works (git clone https://x-access-token:${{ secrets.PAT }}@github.com/ChaiScript/chaiscript.github.io.git), but a deploy key is scoped to just that one repo, which is cleaner from a security perspective.

Want me to update the workflow in this PR to include the deploy job? You'd just need to set up the deploy key / secret on both repos.

@leftibot can it possibly go the other way there the website is triggered to rebuild whenever there's a new artifact on "main" or "develop" here so that we don't need to do the keys and permissions thing?

Unfortunately, there's no fully "zero-auth" way to trigger a cross-repo workflow in GitHub Actions. The workflow_run trigger only works within the same repository, and repository_dispatch (the standard way to trigger repo B from repo A) still requires a token with write access to the target repo.

That said, there's a lightweight approach that avoids deploy keys entirely:

Publish as a GitHub Release asset (no cross-repo auth needed)

1. This repo's workflow attaches the built .js, .wasm, and .html files as assets on a GitHub Release (or even a "rolling" pre-release tag like latest-wasm). Release assets on public repos are downloadable without authentication.

2. The website repo has a simple scheduled workflow (e.g., every 15 minutes or hourly) that:

   • Fetches the latest release from ChaiScript/ChaiScript via the public API
   • Downloads the assets
   • Checks if they differ from what's already committed
   • If changed, commits and pushes → triggers a site rebuild

# In chaiscript.github.io
on:
  schedule:
    - cron: '*/15 * * * *'  # every 15 min

jobs:
  update-playground:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Fetch latest WASM build
        run: |
          mkdir -p playground
          # Public API, no token needed for public repos
          RELEASE=$(curl -s https://api.github.com/repos/ChaiScript/ChaiScript/releases/tags/wasm-latest)
          for file in chaiscript.js chaiscript.wasm chaiscript.html; do
            URL=$(echo "$RELEASE" | jq -r ".assets[] | select(.name==\"$file\") | .browser_download_url")
            curl -sL "$URL" -o "playground/$file"
          done

      - name: Commit if changed
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add playground/
          git diff --cached --quiet || git commit -m "Update ChaiScript playground"
          git push

The tradeoff is up to 15 minutes of latency (or whatever cron interval you pick), but it requires zero secrets, zero keys, zero cross-repo permissions. The website repo just pulls from a public URL.

If you want instant triggering

You'd need at minimum a fine-grained PAT stored as a secret in this repo, scoped to just ChaiScript/chaiscript.github.io with actions:write permission — then this repo sends a repository_dispatch event. It's the lightest auth option for real-time triggering, but it does still require one secret.

The cron-based approach is probably the better fit here given that playground updates aren't time-critical.

@leftibot update this emscripten thing to publish assets under some tag, but only from develop branch, that is then fetchable by the website cron (daily is fine, really) then I'm going to tell you to update the website too.

Addressed review feedback from @lefticus. New commits:

316d605f Address review: publish WASM assets as release under wasm-latest tag