conco/OpenMaidEngine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Plan Linux-hosted Windows release artifacts

Browse Source
This commit is contained in:
gamer147
2026-08-03 20:42:08 -04:00
parent cc65e2cb61
commit 304b290a02
2 changed files with 67 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/platform-portability.md
View File

@@ -84,6 +84,43 @@ lightweight `v0.1.0` tag at `5fe3cd6` on 2026-08-03: the tag build and promotion
the Gitea release carries the archive, archive checksum, build metadata, payload ledger, and smoke log. The Linux
CI/CD path is therefore accepted end to end.
## Planned Windows x64 CI/CD artifact
The Windows artifact will be cross-built on the existing Linux runner; neither a Windows runner nor Wine is part
of its build contract. The .NET SDK publishes `win-x64`, the Linux Godot editor exports through the pinned Windows
x86-64 template, and MinGW-w64 compiles the one project-owned native component. The pinned BtbN Windows FFmpeg
SDK already carries the required headers, runtime DLLs, and MinGW `.dll.a` import libraries. The conditional
`Age.Engine.Text.Windows` project contains managed P/Invoke declarations and therefore compiles on Linux without
loading GDI. Wine would add only an execution test, which is explicitly outside the requested CI gate.
The Windows build command will mirror the accepted Linux entry point while keeping target checks separate. It
will regenerate opcode metadata, selectively install the Windows template from the existing pinned Godot TPZ,
bootstrap/hash-check the pinned Windows FFmpeg SDK, cross-build and inspect `age_movie_ffmpeg.dll`, perform an
exact self-contained `ExportRelease/win-x64` publish, and run the real Godot Windows export. The low-memory publish
proxy will become target-parameterized rather than duplicating its fail-closed project/configuration/RID/output
checks. The accepted Linux path must remain byte- and behavior-compatible throughout this extension.
CI acceptance is structural because the produced executable will not run on the Linux host. The verifier must
require the Windows executable/PCK/self-contained managed directory, `Age.Engine.Text.Windows.dll`, the project
shim, all five pinned FFmpeg DLLs, and the FFmpeg license; reject Linux shared objects and incomplete/cross-target
payloads; and inspect every project-owned PE image as AMD64. The portable ZIP will carry the project license,
third-party notices, clean source/dependency metadata, and a complete payload checksum ledger. A manual packaged
`--package-smoke` command remains available for real-Windows acceptance, but its result is not fabricated or
reported as a hosted CI gate.
Develop, manual, and tag events will run independent Linux and Windows build jobs, each with read-only repository
permission and its own manifest-keyed cache/workflow artifact. Tag promotion will require both jobs, download
both already-built archives, verify their commit/build evidence, and publish two distributable release assets:
`OpenMaidEngine-Himegari-linux-x64.tar.gz` and `OpenMaidEngine-Himegari-windows-x64.zip`. A third small
`RELEASE-SHA256SUMS` attachment will authenticate both archives while keeping the release below Gitea's observed
five-attachment boundary; detailed build metadata, payload ledgers, and logs remain inside each archive and in
the retained workflow artifacts. The release notes will state that Linux received the dynamic package smoke and
Windows received structural cross-target verification only.
Code signing, an installer, Windows-on-Linux execution, and retroactively modifying the accepted Linux-only
`v0.1.0` release are outside this effort. A future signing slice can use `osslsigncode` and protected credentials
without changing how the unsigned portable ZIP is assembled.
## Dependency inventory
| Area | Current dependency | Runtime impact | Portability status / future action |

30
docs/remake-architecture-and-roadmap.md
View File

@@ -1031,6 +1031,36 @@ do not mix mechanical moves with semantic changes.
and the resulting Gitea release exposes all five expected archive/evidence attachments. This accepts the Linux
CI/CD path end to end; future version tags use the same build-once/promote-on-success route.
**Planned Linux-hosted Windows release artifact (2026-08-03):** extend the accepted pipeline without a
Windows runner or Wine. The technical target and verification boundary live in `docs/platform-portability.md`.
The bounded execution order is:
1. **MinGW native foundation.** Add Linux-hosted bootstrap/build scripts over the existing pinned Windows
FFmpeg manifest and its `.dll.a` import libraries. Produce an AMD64 `age_movie_ffmpeg.dll`, copy the exact
five runtime DLLs/license, and verify PE architecture, exported ABI entry points, and FFmpeg imports. Keep
the existing MSVC path as the independent Windows-local builder.
2. **Cross-export and package contract.** Add the Windows x86-64 Godot preset and selectively pinned template;
parameterize the low-memory publish proxy for `win-x64`; generalize package smoke so the downloaded ZIP can
be tested manually on Windows; and add one Linux-hosted `build-windows-x64.sh` entry point. A new Windows
verifier/packager will reject Linux or incomplete payloads and emit a normalized, licensed, checksummed
`OpenMaidEngine-Himegari-windows-x64.zip`. Synthetic package/proxy regressions and a local WSL cross-export
are the slice gate; executing the `.exe` is not.
3. **Hosted Windows artifact job.** Add a read-only Windows-target job beside the existing Linux job on the
same `ubuntu-latest` runner. Provision/report MinGW, cache only hash-verified Godot/FFmpeg inputs, call the
accepted Windows build command, and retain the ZIP plus structural verification/build evidence. A develop
run must leave tag promotion skipped and keep the existing Linux job green.
4. **Dual-platform tag promotion.** Require both build jobs before promotion, download rather than rebuild
their outputs, refactor the release helper around two platform archives, and publish those two distributable
assets plus one combined archive-checksum attachment. Preserve job-local release authority, retry-safe
missing-asset completion, collision refusal, and the existing Gitea attachment ceiling. No version tag is
created until the user explicitly selects one after the hosted develop proof.
**Completion gate:** one deliberately selected future tag produces a single Gitea release containing the
Linux `.tar.gz`, Windows `.zip`, and combined archive checksums; both archives bind to the tag commit, Linux
retains its dynamic packaged smoke, Windows passes all structural PE/payload gates, and neither platform job
receives release-write permission. Signing, installers, Wine, Windows runners, and mutation of `v0.1.0` remain
out of scope.
**Not cleanup targets:** generated `build/` output, the two intentional solution files, historical
`docs/superpowers/` plans/specifications, and fidelity-specific complexity that is directly covered by the
native ABI. Reorganization is successful when ownership and reproduction become clearer, not when the raw