cibuildmp 0.4.0__tar.gz → 0.4.2__tar.gz

{cibuildmp-0.4.0 → cibuildmp-0.4.2}/.github/dependabot.yml

@@ -42,11 +42,37 @@ updates:
   # 0033), since a new base can mean a new libc floor, not just routine
   # hygiene.
   #
-  # `ubuntu:24.04` is out of scope on purpose: every Dockerfile that uses
-  # it names a floating tag, not a digest, and Dependabot's docker
-  # ecosystem has nothing to compare a floating tag against. Digest-pinning
-  # cibuildmp's own base images is a separate decision, not yet made.
+  # `ubuntu:24.04` was assumed out of scope here -- a floating tag, and
+  # Dependabot's docker ecosystem "has nothing to compare a floating tag
+  # against" was this comment's own reasoning until 2026-08-29. Wrong:
+  # Dependabot proposed `ubuntu:24.04` -> `26.04` in its very first grouped
+  # bump (PR #16), and CI caught the reason this needed a human first --
+  # `manylinux_2_39_mipsel.Dockerfile`'s apt-based mipsel cross-toolchain
+  # doesn't exist on 26.04's archive at all (Debian dropped the mipsel
+  # port in Trixie). See docs/records/0068 for the full incident.
   - package-ecosystem: "docker"
     directory: "/docker"
     schedule:
       interval: "weekly"
+    # Six of the Dockerfiles under here pin a real digest (five
+    # `manylinux_2_28_*` arches + `pypa-tracker`), each under a differently
+    # named `quay.io/pypa/...` image -- to Dependabot that's six distinct
+    # dependencies, so without a group a single upstream pypa bump opened
+    # six separate PRs instead of landing as one. Same fix as the
+    # github-actions entry above: one group, one PR per scan regardless of
+    # how many of the pinned images moved.
+    #
+    # `ubuntu` is deliberately excluded from that group (record 0068): a
+    # base-OS major-version bump is not routine hygiene the way a same-name
+    # pypa digest republish is, and grouping the two together is exactly
+    # what let a real break (see above) ride in on the back of nine safe
+    # bumps in one PR with no way to accept one without the other. Excluded
+    # from the group, not ignored outright -- `ubuntu` still gets its own
+    # PR (one, since every Dockerfile referencing it collapses onto the one
+    # dependency name already), just never sharing one with pypa's own.
+    groups:
+      docker-images:
+        patterns:
+          - "*"
+        exclude-patterns:
+          - "ubuntu"

{cibuildmp-0.4.0 → cibuildmp-0.4.2}/.github/workflows/publish-docker-images.yml

@@ -143,6 +143,45 @@ jobs:
           username: ${{ github.actor }}
           password: ${{ github.token }}
 
+      # [0059]'s own incident, made preventable rather than just documented:
+      # the build-push step below always pushes `:latest`, so the instant it
+      # lands, whatever `:latest` pointed to before becomes untagged -- an
+      # OCI index with no tag of its own is exactly what GHCR's "delete
+      # untagged versions" cleanup cannot tell apart from real garbage, and
+      # that cleanup already deleted seven of fifteen published images once
+      # (record 0059), the pin itself never touched. Retagging the digest
+      # `resources/pinned_docker_images.toml` still names -- the one a real
+      # build still depends on until a maintainer's own PR repoints it --
+      # under a name derived from that same digest closes the window: it
+      # keeps its own tag no matter where `:latest` moves next, so a cleanup
+      # run in between publishing and repinning has nothing untagged to find.
+      # No-op (imagetools create is idempotent) if this tag already exists,
+      # and non-fatal if there is nothing pinned yet for a brand-new group.
+      - name: Preserve the digest :latest is about to leave behind
+        if: >-
+          github.event.inputs.only == ''
+          || contains(
+            format(',{0},', github.event.inputs.only),
+            format(',{0},', matrix.image)
+          )
+        run: |
+          set -euo pipefail
+          CURRENT=$(python3 -c "
+          import tomllib
+          with open('src/cibuildmp/resources/pinned_docker_images.toml', 'rb') as f:
+              data = tomllib.load(f)
+          print(data.get('image_group', {}).get('${{ matrix.image }}', ''))
+          ")
+          if [[ "$CURRENT" != ghcr.io/* ]]; then
+            echo "No existing ghcr.io pin for ${{ matrix.image }} yet -- nothing to preserve."
+            exit 0
+          fi
+          DIGEST="${CURRENT#*@sha256:}"
+          docker buildx imagetools create \
+            --tag "ghcr.io/${{ github.repository_owner }}/${{ matrix.image }}:pre-${DIGEST:0:12}" \
+            "$CURRENT" \
+          || echo "::warning::could not preserve the previous digest for ${{ matrix.image }} -- it may already be gone"
+
       - name: Build and push docker/${{ matrix.image }}.Dockerfile
         id: push
         # The `only` input, on each step rather than on the job.

{cibuildmp-0.4.0 → cibuildmp-0.4.2}/.github/workflows/publish.yml

@@ -23,11 +23,14 @@ on:
         type: string
         default: ""
 
-# pull_request here is deliberately build-only: none of the deploy job's environment/if:
-# conditions match a pull_request event, so no publish permissions are ever granted or used.
-# It exists so a packaging change (a missing resources/*.toml in the wheel, a metadata error
-# twine rejects) surfaces on the PR instead of at release time, when the version number is
-# already spent — PyPI will not let the same version be uploaded twice, even after a delete.
+# pull_request here is deliberately build-only: the `build` job (lint, type check, test,
+# `uv build`, `twine check`) still runs, so a packaging change (a missing resources/*.toml in
+# the wheel, a metadata error twine rejects) surfaces on the PR instead of at release time, when
+# the version number is already spent — PyPI will not let the same version be uploaded twice,
+# even after a delete. `deploy` itself does not run at all on pull_request (see its own `if:`) --
+# every one of its steps was already gated behind `push`/`workflow_dispatch`, so it never granted
+# or used publish permissions here, only paid for a checkout that could flake and had nothing to
+# show for succeeding either way.
 run-name: >
   Build & Publish → ${{ github.event_name == 'push' && 'PyPI' ||
       github.event_name == 'workflow_dispatch' && inputs.testpypi && 'TestPyPI' ||
@@ -119,6 +122,15 @@ jobs:
 
   deploy:
     needs: [build]
+    # Every real step below is already gated to `push` (real PyPI) or an
+    # opt-in `workflow_dispatch` (TestPyPI) -- on a `pull_request` event
+    # every one of them was already a no-op (see the comment on the
+    # workflow's own `pull_request` trigger above), so the job itself
+    # skipped doing anything real while still paying for a checkout that
+    # could flake and turn an unrelated PR red for a job that accomplished
+    # nothing on it either way. Confirmed live: exactly that happened on
+    # this repo's own PR #17.
+    if: github.event_name != 'pull_request'
     runs-on: ubuntu-latest
     outputs:
       tag: ${{ steps.meta.outputs.tag }}

{cibuildmp-0.4.0 → cibuildmp-0.4.2}/.github/workflows/test-all-platforms.yml

@@ -23,11 +23,16 @@ name: Test platforms
 # first place -- not upload order, not sorted (docs/records/0065).
 
 on:
-  pull_request:
-    paths-ignore:
-      - "**.md"
-      - "docs/**"
-      - "LICENSE"
+  # No `pull_request` any more: the full real matrix (200+ identifiers,
+  # bucketed across up to 20 concurrent jobs) takes far too long to run on
+  # every PR for how rarely its answer actually changes -- `push`/`pull_request`
+  # CI already runs `tests.yml`'s own unit suite and `build-examples.yml`'s
+  # narrower matrix on every change; this file is for the full sweep,
+  # wanted only occasionally, not gating every PR's own turnaround time.
+  # Weekly by default -- change the cron below, or just run
+  # `workflow_dispatch` by hand whenever a real answer is wanted sooner.
+  schedule:
+    - cron: "0 3 * * 0"
   workflow_dispatch:
     inputs:
       build:
@@ -50,6 +55,12 @@ concurrency:
 
 jobs:
   plan:
+    # No `if: github.actor != 'dependabot[bot]'` guard here any more --
+    # record 0068 added it specifically for the `pull_request` trigger a
+    # Dependabot docker/dependabot.yml PR would otherwise fire this on;
+    # dropping that trigger entirely (this file's own header comment) makes
+    # the guard moot, not just redundant, since `schedule`/`workflow_dispatch`
+    # never runs as that actor in the first place.
     runs-on: ubuntu-latest
     outputs:
       identifiers: ${{ steps.plan.outputs.identifiers }}
@@ -115,6 +126,10 @@ jobs:
   # passed back through `build`'s own outputs.
   aggregate-results:
     needs: [plan, build]
+    # `always()`: render a summary even if a bucket in `build` failed --
+    # `test-platforms.yml`'s own `--keep-going` (record 0063) means a real
+    # failure there still uploads a report, and this is what turns every
+    # bucket's own report into the one table worth looking at.
     if: always()
     runs-on: ubuntu-latest
     steps:

{cibuildmp-0.4.0 → cibuildmp-0.4.2}/.github/workflows/test-platforms.yml

@@ -86,6 +86,18 @@ jobs:
     # Job-level, not set on the `uses: ./` step itself -- a composite
     # action's own inner steps are only guaranteed to see `env:` declared
     # at job/workflow level, not on the specific step that calls `uses:`.
+    #
+    # Every value below is a plain literal or references only `inputs.*`/
+    # `env.*` -- deliberately. `.github/workflows/test-upstream-usermodule.yml`
+    # (docs/records/0069) tried putting a `${{ runner.temp }}`- and then a
+    # `${{ github.workspace }}`-based expression in a job-level `env:` value
+    # here and got a genuine "invalid workflow file" both times (zero jobs
+    # ever created) -- confirmed live, twice, but *which* part of that shape
+    # GitHub's schema actually rejects was not pinned down with real
+    # confidence (0069's own addendum has the detail and the open question).
+    # Until that is resolved elsewhere, treat a runner-scoped context
+    # (`runner.*`, and possibly `github.workspace`) in a job-level `env:`
+    # value as unproven here, not safe to copy.
     env:
       CIBMP_VERSION: 0.0.0-ci
       # A real env var, not routed through the `skip:` input/`action.yml`'s

cibuildmp-0.4.2/.github/workflows/test-upstream-natmod.yml

@@ -0,0 +1,131 @@
+name: Test upstream natmod
+
+# Builds every one of MicroPython's own eleven `examples/natmod/*` modules
+# through cibuildmp's real natmod path -- docs/records/0055 scoped why this
+# fixture matters (it tests upstream's own natmod contract, not the one this
+# project wrote for itself in `examples/template/natmod`) and found that
+# contract does not fit unmodified; docs/records/0072 is the mechanism
+# actually landed here and explains every choice below in full.
+#
+# build-features0: one job, deliberately building *two* arches for the same
+# tag in a single invocation, not two separate single-arch jobs: [0055]'s own
+# guard survey is entirely about what happens when cibuildmp builds several
+# targets back to back in one checkout (a stale artifact, or an unscoped
+# `build/`, silently carrying the *previous* target's binary into the next
+# one's output) -- a job that only ever builds one target at a time would
+# never actually exercise that risk. `verify_output()` (build.py, already
+# part of every real build) is the check that would catch it: a wrong arch
+# code in the .mpy header fails the build outright rather than shipping
+# silently wrong -- but `examples/natmod/cibuildmp.toml`'s own
+# `pre-build-command` (record 0072) removes the possibility structurally,
+# for this same reason armv7emsp is a second *real* cross-compiled arch here
+# and not just a second easy one: it shares this checkout and this same
+# invocation with x64, the one thing a single-arch job can never test.
+#
+# build-upstream-natmod: the other ten modules, one `x64` build each (no
+# arch-collision risk to re-prove per module -- that mechanism is
+# `examples/natmod/cibuildmp.toml`'s own, verified once above, not a
+# property of any one module's Makefile). `CIBMP_MODULE_DIR` overrides that
+# file's own `features0` default per matrix entry -- `{micropython}` resolves
+# the same way regardless of which layer supplied `module-dir` (record 0072).
+# `btree` needs no `micropython-submodules` entry for its own
+# `lib/berkeley-db-1.xx`: `sources.fetch_micropython()` prefers the release
+# tarball, which already vendors every `lib/` submodule -- confirmed 2026-08-31
+# against a real, tarball-fetched v1.29.0 checkout, on the bare host (no
+# Docker in that session), building and `verify_output()`-checking all eleven
+# modules for `x64` -- not assumed from [0055]'s own original, narrower
+# "needs a submodule" citation (see docs/records/0072's own addendum).
+#
+# `examples/natmod/cibuildmp.toml` carries the whole mechanism otherwise --
+# `make-target = "all"` (upstream's examples define no `dist` target at all)
+# and its own `pre-build-command` clearing every `.mpy` plus the whole build
+# tree before *every single* build. No job here sets either directly -- a
+# bare `cibuildmp examples/natmod --build <identifier>` run, CI or local,
+# resolves identically to what a job here does (module-dir aside, for the
+# ten `CIBMP_MODULE_DIR`-overridden ones).
+#
+# No `docker/setup-qemu-action` needed anywhere here, unlike
+# test-upstream-usermodule.yml's rp2/esp32/qemu legs: `dockerrun.platform_for()`
+# resolves every non-`unix` port -- natmod included -- to a flat
+# `linux/amd64`, confirmed directly against that function's own source, so
+# every natmod image already runs native on a `ubuntu-latest` runner
+# regardless of which arch's toolchain it carries.
+#
+# push: (no branches: filter), same reasoning build-examples.yml's own header
+# already documents -- this needs to run on every push to a dev branch too.
+
+on:
+  push:
+  pull_request:
+    paths-ignore:
+      - "**.md"
+      - "docs/**"
+      - "LICENSE"
+  workflow_dispatch:
+
+concurrency:
+  group: test-upstream-natmod-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+env:
+  # Single source of truth for this job -- bump here, not by hand in the
+  # `build` line below, when this fixture moves to a newer tag. `mpy6.3`
+  # is that tag's own natmod ABI (`identifier_format = "mpy{mpy}-{tag}-
+  # {arch}"`, resources/build-platforms.toml), not an independent value --
+  # a tag bump that also changes ABI needs this updated too.
+  CIBMP_UPSTREAM_ABI_TAG: mpy6.3-v1.29.0
+
+jobs:
+  # x64: a plain native arch, no cross-compiler at all (`images.x64 =
+  # "natmod_host"`) -- the cheapest possible leg.
+  #
+  # armv7emsp: a real cross-compiled arch (`arm-none-eabi-`, `images.
+  # armv7emsp = "arm_embedded"`) sharing this same checkout and this same
+  # `cibuildmp` invocation with x64 above -- the leg that actually exercises
+  # [0055]'s own finding, not just a second easy arch for breadth's sake.
+  build-features0:
+    runs-on: ubuntu-latest
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Build upstream examples/natmod/features0 (x64 + armv7emsp)
+        uses: ./
+        with:
+          package-dir: examples/natmod
+          build: "${{ env.CIBMP_UPSTREAM_ABI_TAG }}-x64 ${{ env.CIBMP_UPSTREAM_ABI_TAG }}-armv7emsp"
+
+      - name: List built artifacts
+        run: ls -laR examples/natmod/mpyhouse
+
+  build-upstream-natmod:
+    strategy:
+      fail-fast: false
+      matrix:
+        module:
+          - features1
+          - features2
+          - features3
+          - features4
+          - heapq
+          - random
+          - re
+          - deflate
+          - framebuf
+          - btree
+    runs-on: ubuntu-latest
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+      CIBMP_MODULE_DIR: "{micropython}/examples/natmod/${{ matrix.module }}"
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Build upstream examples/natmod/${{ matrix.module }} (x64)
+        uses: ./
+        with:
+          package-dir: examples/natmod
+          build: "${{ env.CIBMP_UPSTREAM_ABI_TAG }}-x64"
+
+      - name: List built artifacts
+        run: ls -laR examples/natmod/mpyhouse

cibuildmp-0.4.2/.github/workflows/test-upstream-usermodule.yml

@@ -0,0 +1,241 @@
+name: Test upstream usercmodule
+
+# Builds MicroPython's own `examples/usercmodule/` (cexample, cppexample,
+# subpackage) through cibuildmp's real usermod path -- docs/records/0054
+# scoped why this fixture matters (it tests upstream's own module contract,
+# not one this project wrote for itself); docs/records/0069 is the mechanism
+# actually landed here and explains every choice below in full.
+#
+# Six jobs, one per port cibuildmp drives a usermod build for -- widened
+# from the original narrow unix+rp2 slice ([0054]'s own "one Make port and
+# one CMake port is enough to answer the three questions above") once that
+# slice came back green, per [0054]'s own "widen only if it finds
+# something." Still nowhere near build-examples.yml's much broader
+# examples/template matrix: one representative identifier per port, not
+# each port's own full arch/board matrix.
+#
+# No job here sets `CIBMP_USER_C_MODULES`/`CIBMP_EXTRA_MAKE_ARGS`/
+# `CIBMP_EXTRA_CMAKE_ARGS`, and none of them ever resolves the pinned
+# checkout itself. Both used to be true: every job called
+# `sources.fetch_micropython()` directly, in its own pre-fetch step, then
+# exported the real checkout path by hand -- necessary back when this
+# project had no way to name "a path inside whatever checkout cibuildmp
+# itself is about to fetch" from outside cibuildmp, and no way to say "this
+# one identifier needs this one extra flag" from inside a config file
+# meant to be shared by all six. `examples/usercmodule/cibuildmp.toml` now
+# carries all of it -- no `user-c-modules =` at all any more, for any
+# port: the built-in "." default is already right on both sides once
+# each side has its own real entry point (`micropython.cmake` for the two
+# CMake ports, `{cexample,cppexample,subpackage}/micropython.mk` for the
+# four Make ports -- see that toml's own header comment), plus
+# `[override."*-wasm32"]`'s own `extra-make-args` -- so a bare
+# `cibuildmp examples/usercmodule --build <identifier>` run, CI or local,
+# resolves identically to what a job here does. `build` stays out of that
+# file on purpose (see its own header comment): each job below still wants
+# exactly one identifier per push, not this fixture's full six-port sweep,
+# and that is the one thing a shared config file cannot express per-job.
+#
+# An even leaner shape was tried before any of this and reverted: pin
+# `CIBMP_CACHE_PATH` to a fixed, known directory so the checkout's
+# eventual path becomes computable without fetching it at all. That broke
+# the workflow file outright, twice, for a GitHub Actions job-level-`env:`
+# scoping rule this session could not conclusively pin down live -- see
+# docs/records/0069 for the full account, kept for whoever revisits it
+# rather than guessed away.
+#
+# push: (no branches: filter), same reasoning build-examples.yml's own header
+# already documents -- this needs to run on every push to a dev branch too.
+
+on:
+  push:
+  pull_request:
+    paths-ignore:
+      - "**.md"
+      - "docs/**"
+      - "LICENSE"
+  workflow_dispatch:
+
+concurrency:
+  group: test-upstream-usermodule-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+env:
+  # Single source of truth for every job below -- bump here, not six
+  # times, when this fixture moves to a newer tag.
+  CIBMP_UPSTREAM_TAG: v1.29.0
+
+jobs:
+  # ── unix: the Make side ─────────────────────────────────────────────
+  #
+  # py/py.mk's own `<USER_C_MODULES>/*/micropython.mk` glob finds
+  # `examples/usercmodule/{cexample,cppexample,subpackage}/micropython.mk`
+  # -- this fixture's own thin wrappers, each `include`ing upstream's real
+  # file via `$(TOP)` (see `cexample/micropython.mk`'s own header comment)
+  # -- with `user-c-modules` at its built-in "." default, no override
+  # needed. Never vendored (0054): the real content still comes from the
+  # pinned checkout, only three one-line `include` shims live in this repo.
+  build-unix:
+    runs-on: ubuntu-latest
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Build upstream examples/usercmodule (unix, native)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-manylinux_2_28_x86_64
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse
+
+      # A linked binary is not the same claim as one whose modules actually
+      # run -- unix is the one port here whose own output this runner can
+      # simply execute (a real manylinux_2_28 binary runs unmodified on a
+      # newer-glibc host, the whole point of the manylinux floor), unlike
+      # rp2's own firmware.uf2, which needs real hardware. See
+      # smoke_test.py's own header for what it actually exercises.
+      - name: "Smoke test (unix): run the built binary against smoke_test.py"
+        run: |
+          set -euo pipefail
+          identifier="${CIBMP_UPSTREAM_TAG}-manylinux_2_28_x86_64"
+          bin="examples/usercmodule/mpyhouse/${identifier}/micropython-${identifier}"
+          "$bin" examples/usercmodule/smoke_test.py
+
+  # ── rp2: the CMake side ──────────────────────────────────────────────
+  #
+  # Chosen over esp32 purely on cost -- usermod/build_rp2.py's own docstring:
+  # the Pico SDK arrives as `lib/` submodules of the MicroPython checkout
+  # itself, no separate host-side toolchain resolver the way esp32's
+  # ESP-IDF needs. Nothing here is rp2-specific; widening to esp32/windows/
+  # webassembly/qemu is exactly [0054]'s own "widen only if it finds
+  # something" (docs/records/0069).
+  #
+  # This is also the leg that actually answers [0054]'s biggest open
+  # question for one real toolchain: whether cppexample's `-lstdc++` is
+  # satisfiable on a bare-metal cross target. Deliberately not skipped --
+  # a red leg here is a real finding to record, not a bug in this workflow.
+  #
+  # examples/usercmodule/micropython.cmake resolves the pinned checkout
+  # itself, via MICROPY_DIR -- a CMake variable every CMake port already
+  # sets before it ever include()s a user module (rp2/CMakeLists.txt's own
+  # `get_filename_component(MICROPY_DIR "../.." ABSOLUTE)`, well before its
+  # own `include(${MICROPY_DIR}/py/usermod.cmake)`) -- with `user-c-modules`
+  # at its built-in "." default, same as every other port here now.
+  build-rp2:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+      - uses: docker/setup-qemu-action@v4
+
+      - name: Build upstream examples/usercmodule (rp2)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-rp2-RPI_PICO
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse
+
+  # ── esp32: the second CMake port, and the second bare-metal toolchain ──
+  #
+  # [0054]'s own list of unanswered families after [0069]: esp32 is the
+  # ESP-IDF one -- a cmake-driven port like rp2, but a materially different
+  # toolchain (Xtensa/RISC-V via idf.py, not arm-none-eabi via the Pico
+  # SDK). Fully containerized since [0028] (no host-side ESP-IDF resolver
+  # left).
+  #
+  # Same MICROPY_DIR mechanism as build-rp2 above: MICROPY_DIR is set at
+  # the very top of ports/esp32/main/CMakeLists.txt
+  # (`if(NOT MICROPY_DIR) get_filename_component(...)`), well before it --
+  # via ports/esp32/CMakeLists.txt -- reaches `include(${MICROPY_DIR}/py/
+  # usermod.cmake)`.
+  build-esp32:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+      - uses: docker/setup-qemu-action@v4
+
+      - name: Build upstream examples/usercmodule (esp32)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-esp32-ESP32_GENERIC
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse
+
+  # ── windows, webassembly, qemu: the remaining three Make ports ──────────
+  #
+  # Same mechanism as build-unix above (the same three wrapper files,
+  # already discovered by py.mk's own glob), one representative identifier
+  # per port rather than each port's own full arch matrix -- [0054]'s own
+  # "widen only if it finds something", not a cost-blind repeat of
+  # build-examples.yml's broader coverage. No smoke test for any of the
+  # three: none of their outputs (a .exe, a .wasm, a qemu ELF) runs
+  # directly on this runner the way unix's manylinux binary does (record
+  # 0069's own reasoning for why rp2 has none either).
+  build-windows:
+    runs-on: ubuntu-latest
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Build upstream examples/usercmodule (windows)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-win_amd64
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse
+
+  # `examples/usercmodule/cibuildmp.toml`'s own `[override."*-wasm32"]`
+  # carries this identifier's own `extra-make-args` (CXX=em++ plus the
+  # CXXFLAGS_MOD fix for two real, separate upstream ports/webassembly/
+  # Makefile bugs -- see that file's own comment for both). Nothing
+  # webassembly-specific is set here any more.
+  build-webassembly:
+    runs-on: ubuntu-latest
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Build upstream examples/usercmodule (webassembly)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-wasm32
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse
+
+  build-qemu:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    env:
+      CIBMP_VERSION: 0.0.0-ci
+    steps:
+      - uses: actions/checkout@v7
+      - uses: docker/setup-qemu-action@v4
+
+      - name: Build upstream examples/usercmodule (qemu)
+        uses: ./
+        with:
+          package-dir: examples/usercmodule
+          build: ${{ env.CIBMP_UPSTREAM_TAG }}-qemu-MPS2_AN385
+
+      - name: List built artifacts
+        run: ls -laR examples/usercmodule/mpyhouse