Skip to content

Add WASM extension artifact publishing workflow#396

Open
adamziel wants to merge 7 commits intotrunkfrom
codex/publish-wasm-extension-artifact
Open

Add WASM extension artifact publishing workflow#396
adamziel wants to merge 7 commits intotrunkfrom
codex/publish-wasm-extension-artifact

Conversation

@adamziel
Copy link
Copy Markdown
Collaborator

@adamziel adamziel commented May 3, 2026

What it does

Builds a Playground-loadable wp_mysql_parser WASM PHP extension bundle for PHP 8.0 through 8.5.

On trunk pushes or manual workflow_dispatch, the new publish workflow:

  1. Builds one JSPI side module per PHP version.
  2. Uploads the collected bundle as an Actions artifact named wp_mysql_parser-wasm-extension.
  3. Publishes the same files to the gh-pages branch:
wp_mysql_parser-wasm-extension/latest/manifest.json
wp_mysql_parser-wasm-extension/<commit-sha>/manifest.json

The latest/ path is replaced on every publish. The <commit-sha>/ path is immutable.

Rationale

Playground needs public manifest.json and .so files it can fetch at runtime. An Actions artifact is useful for debugging, but it is not a stable public URL and should not be treated as a production plugin release.

Publishing the bundle from gh-pages gives Playground a static URL without repackaging the WordPress plugin itself. The repository still needs GitHub Pages configured to publish from the gh-pages branch root before these URLs resolve:

https://wordpress.github.io/sqlite-database-integration/wp_mysql_parser-wasm-extension/latest/manifest.json
https://wordpress.github.io/sqlite-database-integration/wp_mysql_parser-wasm-extension/<commit-sha>/manifest.json

PHP 7.4 is intentionally excluded. The Rust path uses ext-php-rs 0.15, which depends on PHP 8 Zend APIs.

Implementation

Adds .github/workflows/publish-wasm-extension-artifact.yml with a serialized PHP matrix for 8.5, 8.4, 8.3, 8.2, 8.1, and 8.0. The package job downloads the per-version .so artifacts, writes a combined Playground extension manifest, writes SHA256SUMS, uploads the bundle, then commits the static bundle to gh-pages.

The manifest follows the WordPress Playground extension format from WordPress/wordpress-playground#3580:

{
  "name": "wp_mysql_parser",
  "mode": "php-extension",
  "artifacts": [
    {
      "phpVersion": "8.4",
      "sourcePath": "wp_mysql_parser-php8.4-jspi.so"
    }
  ]
}

The manifest uses sourcePath and does not include the retired file or sha256 artifact fields. Checksums are published separately in SHA256SUMS.

The Rust build now runs the published @php-wasm/compile-extension@3.1.27 CLI from an isolated temporary npm prefix. A sparse WordPress/wordpress-playground checkout is still required for packages/php-wasm/compile Docker assets and for the Playground load smoke test.

Follow-up for Playground: make @php-wasm/compile-extension self-contained so external extension projects do not need to shallow or sparse checkout WordPress/wordpress-playground just to access Docker assets or test harness files.

Testing instructions

Run the local static checks:

bash -n packages/php-ext-wp-mysql-parser/wasm-spike/build-in-docker-rust.sh
actionlint .github/workflows/wasm-spike.yml .github/workflows/publish-wasm-extension-artifact.yml
node --check packages/php-ext-wp-mysql-parser/wasm-spike/write-extension-manifest.mjs
git diff --check

Verify the PR WASM extension build check is green for PHP 8.0 through 8.5. The latest PR run passed all six PHP versions.

After merge, run Publish WASM extension artifact with workflow_dispatch or let a matching trunk push trigger it, then verify both published manifests resolve from GitHub Pages once Pages is configured for the gh-pages branch root.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant