Release packaging as a repeatable workflow
Rubra Packager is a Windows desktop workstation for the less glamorous part of shipping a web game: taking a trusted static project, checking that the package is coherent and producing a target build without repeating the same manual release steps every time.
The project lives in the Rubra-Composer repository. The current site baseline is v0.5.0 — Active Development.
What v0.5.0 covers
Register projects once
The Projects shelf stores a source folder together with its packaging profile and release metadata. Profiles such as Arena Rubra, Generic Web Game and Generic HTML App define required paths, target defaults and FULL/LITE exclusion rules.
That keeps packaging policy out of the game source itself and makes repeated builds easier to reproduce.
Preflight before packaging
A build should fail early for the right reason.
Preflight scans the selected variant, reports included and excluded files, estimates package size and separates blocking errors from warnings. Static HTML/CSS references, local JavaScript module imports and static new URL(..., import.meta.url) assets can be checked directly; dynamic runtime-generated paths are not guessed.
Windows executable output
The Windows workspace prepares a one-file desktop executable using the project’s Windows packaging stack. Application name, profile, variant and custom icon stay visible before the build starts.
The source repository documents the Windows path as a PyInstaller + PyWebView package rather than a generic Python-to-EXE converter.
Android APK and AAB output
Android packaging adds a separate toolchain: Java, Android SDK, Node.js/npm and the Gradle/Capacitor build path.
The v0.5.0 interface exposes debug/release-oriented Android output, APK/AAB selection, launcher icon configuration and release-signing fields. Those controls are deliberately kept separate from the Windows path so platform requirements are visible.
Supported static source layouts
Rubra Packager recognizes a root index.html or common static output folders including:
dist/build/out/.output/public/- Gatsby
public/when Gatsby is detected - Angular-style
dist/<project>/browser/
The boundary is intentional: a framework project must produce a real static index.html. Server-side rendering, backend APIs and dynamic routes are outside the current packaging scope.
Trust is part of the product design
Sometimes the requested source is not already built. Rubra Packager can then invoke npm install and npm run build, but package scripts are executable code.
The UI therefore requires an explicit trust choice before source execution. That warning is not decorative; it is part of the release model.
Why build this instead of another one-off script?
Arena Rubra and the smaller GVibeDev web experiments repeatedly needed the same operations: locate a static output, validate required assets, package the correct variant, configure icons, build for a target and verify the resulting artifact.
Rubra Packager turns that repeated release work into a visible, inspectable workflow:
Register → Preflight → Fix → Build → Verify
The goal is not to hide packaging behind one magic button. It is to make the steps repeatable enough that a build can be understood when something goes wrong.
