Windows on ARM: finish the native build, and stop writing the import gate twice - #7
Merged
Merged
Conversation
The native ARM64 build worked. It produced both installers — FlowMap_1.3.1_arm64_en-US.msi and FlowMap_1.3.1_arm64-setup.exe — and bundle-python.sh's own gate imported all 26 modules the target ships. Then the release workflow's smoke test failed on `No module named 'pyarrow'`, because it carried a second, inline copy of the same module list, and that copy still demanded the one module the bundler had been told — correctly, and in writing — not to install. Two copies of a list is one copy too many the moment any target needs an exception. The list now lives once, in app/scripts/import-gate.py, and both callers run it. bundle-python.sh writes what it excluded to resources/.import-skip so the later, separate workflow step gates on exactly what was built without being told again; the file is rewritten on every run so a skip cannot leak from a previous target in the same checkout, and a skip naming a module the gate never checked is an error, not a silent no-op. Exercised in all five modes: full environment (27 import), exclusion via env (26 + 1 skipped), exclusion via the sidecar (same), no exclusion in a pyarrow-free environment (fails, naming pyarrow), and a bogus skip name (exit 2). Also `tee` the installer-size table to stdout, not just the step summary: step summaries are not readable through the API, so a dry-run build was reporting sizes that nothing could then fetch to update the download tables with.
Eight installers now, not six: Windows on ARM gets its own setup.exe and MSI, and they are native ARM64 rather than the x64 build under emulation. Every size in the table is what CI measured on the leg that produced the file, on a build where all five legs went green — the previous table had drifted far enough that both DMG figures were wrong by 15-20 MB in the same direction, which is what happens when the numbers are typed rather than read. The workflow's size report now prints exact bytes alongside `du -h`, since a rounded MiB cannot be converted back into the MB a download table quotes. The ARM64 build's one deliberate difference is stated rather than hidden: pyarrow has no win_arm64 wheel anywhere, so that bundle omits it and pins cryptography back to the last version that has one. Neither is on a path FlowMap uses, and the release gate re-proves that by importing the full lazy closure on the machine that built the bundle.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
maincannot cut an ARM64 release as it stands. PR #5 added thewindows-11-armleg and the win-arm64 dependency exceptions, but the releaseworkflow kept a second, inline copy of the import-gate module list — and
that copy still demanded
pyarrow, the one module the bundler had been told, inwriting, not to install. The ARM64 leg built both installers, passed its own
gate, and then failed the workflow's.
What is in here
app/scripts/import-gate.py;bundle-python.shand the release workflow both run it. The bundler writes whatit excluded to
resources/.import-skipso the later, separate workflow stepgates on exactly what was built without being told again. The file is rewritten
every run (a skip cannot leak from a previous target in the same checkout), and
a skip naming a module the gate never checked is an error, not a silent no-op.
every size read off the leg that produced the file.
du -h, andtees to stdout:step summaries are not readable through the API, so a dry-run was reporting
numbers nothing could fetch.
Verification
Dry-run build 30467653073 — all five legs green:
/api/healthwindows-11-arm(aarch64-pc-windows-msvc)FlowMap_1.3.1_arm64-setup.exe86 MiB ·FlowMap_1.3.1_arm64_en-US.msi151 MiBwindows-latest(x86_64)x64-setup.exe115 MiB ·x64_en-US.msi188 MiBmacos-14FlowMap_1.3.1_aarch64.dmg176 MiBmacos-15-intelFlowMap_1.3.1_x86_64.dmg176 MiBubuntu-22.04amd64.deb457 MiB ·amd64.AppImage338 MiB(
macos-14first hithdiutil: create failed - Resource busy, a DMG-creationflake — the same script had passed on the two previous runs and passed on rerun.)
The gate itself was exercised in all five modes: full environment (27 import),
exclusion by env (26 + 1 skipped), exclusion by sidecar (same), no exclusion
in a pyarrow-free environment (fails, naming pyarrow), and a bogus skip name
(exit 2).
Branched off
main, so it is independent offeat/verifiable-releases.