Devops rework by MattSzymonski · Pull Request #43 · Pillware/Pill

MattSzymonski · 2026-07-03T10:39:57Z

Comprehensive overhaul of the Pill project infrastructure, launcher architecture, and developer tooling.

Pill Launcher Refactoring

The launcher's monolithic main.rs (~1,400 lines) has been split into a trait-based action dispatch architecture:

8 action modules under actions/ - build, run, create, docs, cargo, assets, link, unlink
11 utility modules under utils/ - cli, common, files, paths, native_target, wasm_target, web_dev_server, workspace, assets, plantuml
Each action implements the Action trait and registers its own CLI flags with clap
Improved CLI subcommand, argument, and flag handling - every subcommand has context-sensitive --help
Detailed doc comments on every file, every function, and in function scopes

CI Pipeline Overhaul

The old monolithic ci.yml has been replaced with 4 focused GitHub Actions workflows:

Workflow	Trigger	What it does
`ci-basic-tests.yml`	Every push	5 parallel fast checks (fmt, clippy, native build, WASM+budget, benchmark)
`ci-build-image.yml`	Dockerfile changes	Builds & pushes Docker CI image
`ci-examples-tests.yml`	Daily	Builds all 8 example projects
`ci-pill_launcher-tests.yml`	Daily	Exhaustive launcher action suite (9 test groups)

The actual test logic lives in 3 bash test scripts with shared infrastructure (common.sh):

Script	Coverage
`run_basic_tests.sh`	fmt, clippy, native/WASM builds, size reports, WASM budget guard (0.499 MiB), performance benchmark (City, 3 runs)
`run_examples_tests.sh`	Compiles all Pill examples + standalone crates with size reports
`run_pill_launcher_tests.sh`	9-group exhaustive test covering every subcommand, flag, and error path

CI runs locally - bash devops/tests/run_basic_tests.sh
On GitHub it runs in Docker - ghcr.io/mattszymonski/pill-ci:latest (Alpine + Rust + wasm-pack + slangc + plantuml)

New: Build Size & Performance Benchmarks

The CI pipeline now includes automated tracking of binary sizes and frame-time performance on every push:

Build size reports - every native and WASM build emits a JSON snapshot of all output files in mebibytes (MiB). Native builds report every DLL/executable in build/release/data/; WASM builds report the .wasm binary. Size regressions (e.g. pill_runtime.dll jumping from 10 MB to 15 MB) are immediately visible in CI logs.
Performance benchmark - examples/city (10,000 citizens, 5,000 frames) is built and run 3× on every push. Per-frame timing statistics (average_ms, median_ms, min_ms, max_ms, range_ms, stddev_ms) are extracted from the game's JSON output and aggregated across runs. Supports both windowed and headless modes with automatic fallback.
WASM size guard - the .wasm binary is checked against a hard budget of 0.499 MiB (523,239 bytes). Exceeding it fails the CI check, preventing accidental binary bloat from new dependencies or missing optimizations.

Examples & Templates

New benchmark example: examples/city - 10,000 citizens, 5,000 frames, JSON frame-time output, supports windowed & headless modes
Template renamed: pill_default → new_project
Entry point renamed: game.rs → project.rs across all examples - projects no longer use lib.rs, only project.rs is needed
Removed: examples/Empty (consolidated)
All example Cargo.toml files updated for new template paths

Naming: Game → Project

The term "game" has been renamed to "project" throughout the codebase, reflecting that Pill supports more than just games.

Documentation added:

JDuchniewicz · 2026-07-13T10:07:40Z

+    let mut content = String::new();
+    for line in template.lines() {
+        let trimmed = line.trim_start();
+        if trimmed.starts_with("workspace ") || trimmed.starts_with("workspace=") {


why do we tolerate 2 options?

JDuchniewicz · 2026-07-13T10:08:08Z

+            content.push_str("[workspace]\nresolver = \"2\"\n");
+        } else if trimmed.starts_with("pill_engine ") || trimmed.starts_with("pill_engine=") {
+            content.push_str(&format!(
+                "pill_engine = {{ path = \"{pill_engine}\", features = [\"project\", \"internal\"] }}\n"


also, as mentioned above - I don't think project option is a good way ahead

JDuchniewicz · 2026-07-13T10:17:52Z

+}
+
+/// Copy the WASM template into a scratch directory so the engine workspace stays pristine.
+pub(crate) fn prepare_scratch_crate(


can we name all WASM-related functions with a wasm_ prefix? This way until we have another usege for them they can be distinguished as wasm-only functions.

JDuchniewicz · 2026-07-13T10:19:05Z

+
+/// Resolve Git-on-Windows pseudo-symlinks (small text files containing a relative path).
+/// Real symlinks and regular files pass through unchanged.
+pub(crate) fn resolve_pseudo_symlink(path: &Path) -> PathBuf {


maybe Windows-only helpers should not bloat non-Windows builds? Add platform flag please

JDuchniewicz · 2026-07-13T15:20:39Z

+/// Panics if the engine workspace directory cannot be found.
+pub(crate) fn get_path(location: Location) -> PathBuf {
+    // engine workspace directory = .../Pill-Engine/engine
+    let engine_workspace =


this is a quite heavy operation all in all - we will be traversing up to find the desired directory. I think we could cache this somehow so that we don't find it each time. Unless this is called with various different paths from various locations - then it's hard to cache it once for all. I would prefer, though to establish it once and forget about it and use a common relative path everywhere to a known root.

JDuchniewicz · 2026-07-13T15:34:47Z

+            BuildTarget::Web => {
+                let port: u16 = matches
+                    .value_of("wasm-port")
+                    .unwrap_or("8080")


why 2 level unwrapping here?

JDuchniewicz · 2026-07-13T16:13:18Z

 pill_runtime = { path = "../pill_runtime" }

-winit = "0.30.12"
+winit = "0.30"


again partial bumps

JDuchniewicz · 2026-07-13T16:15:34Z

-//   vec3  fog_color;       // offset 0  (12 bytes)
-//   float fog_density;     // offset 12 (4 bytes)
-//   // total: 16 bytes
+//   float3 fog_color;      // offset 0, size 12, but std140 aligns vec3 to 16


this will soon get deprecated - are these changes necessary?

JDuchniewicz · 2026-07-13T16:15:51Z

 # Other
-glam = { version = "0.30.8", features = ["serde", "bytemuck"] }
-winit = "0.30.12"
+glam = { version = "0.33", features = ["serde", "bytemuck"] }


partial updates

JDuchniewicz · 2026-07-13T16:16:19Z

 console_log = "1"
 log = { version = "0.4", features = ["release_max_level_off"] }
-winit = { version = "0.30.12" }
+winit = { version = "0.30" }


partial updates

JDuchniewicz · 2026-07-13T16:16:44Z

    "pill_native",
    "pill_web",
    "pill_runtime",
-    "NO_PATH", ### Game project crate (This will be changed by Pill Launcher on build to allow proper compilation of game project)


glad we got rid of that 🍾 good job!

JDuchniewicz · 2026-07-13T16:20:58Z

+## CI
+
+A dedicated `benchmark` job runs on every push to `main` and every PR. It uses
+`benchmark_windowed` mode with `xvfb-run` for a virtual display on headless runners.


is this mode still valid? Did not see something like that in the commits.

this xvfb-run

JDuchniewicz · 2026-07-13T16:24:01Z

+
+const BENCHMARK_CITIZEN_COUNT: usize = 10_000;
+const BENCHMARK_DEFAULT_MAX_FRAMES: u64 = 5_000;
+const BENCHMARK_WARMUP_FRAMES: u64 = 1_000;


do we need 1000 frames? Usually it's enough to run N times where N is the size necessary for warming up all caches - I encountered up to 100 iterations in other projects, so maybe we don't need that many. Sometimes it's also good to discard the last N frames that introduce outliers - though this can imply some weird platform-specific hoodoo.

I link here a good resource on this topic for posterity https://gernot-heiser.org/benchmarking-crimes.html

JDuchniewicz · 2026-07-13T16:24:54Z

+                    .build(),
+            )?;
+            let _orange = engine.add_resource::<Material>(
+                Material::builder(shared::ORANGE_MATERIAL_NAME)


JDuchniewicz · 2026-07-13T16:27:03Z

+                shared::PLANE_MESH_NAME,
+                shared::PLANE_MESH_PATH.into(),
+            ))?;
+            let _pill = engine.add_resource(Mesh::new(


JDuchniewicz · 2026-07-13T16:30:53Z

+    #[cfg(feature = "benchmark_windowed")]
+    let (orange_material, pill_mesh) = {
+        let material = engine.get_resource_handle::<Material>("orange")?;
+        let mesh = engine.get_resource_handle::<Mesh>("pill")?;


ah, pill's material and mesh are created only for non-headless builds?, then maybe gate them behind headless?

JDuchniewicz · 2026-07-13T16:42:01Z

+// -- Statistics --------------------------------------------------------------
+
+fn print_report(state: &BenchmarkState) {
+    let times = &state.frame_times_ms;


this might be me being too picky, but there is a danger of storing values during benchmarking - as explained in the below slide:

It's often better to have rolling sums as this eliminates writing to memory, especially if the frame_times_ms does not fit in cache.

JDuchniewicz · 2026-07-13T17:01:33Z

@@ -0,0 +1,266 @@
+//! This file implements the headless runner, activated by the `headless` feature.
+//!
+//! Replaces the winit-based run_app() with a bare update loop — no window,


vernacular is a bit LLMish - "3 times 'no'" then "fully supported" -how can it be partially supported :D

JDuchniewicz · 2026-07-13T17:09:46Z

+            .join("pill_launcher")
+            .join("target")
+            .join("debug")
+            .join("PillLauncherUpstream"),


is this standardized somewhere? I did not see it anywhere else yet.

JDuchniewicz · 2026-07-13T17:16:11Z

+        //    initialise a fresh engine inside the new runtime.
+        let project_dylib_path =
+            CString::new(project_path_for_create.to_string_lossy().as_bytes())?;
+        let args = if let Some(ctx) = runtime_context {


Suggested change

let args = if let Some(ctx) = runtime_context {

let args = if let Some(context) = runtime_context {

JDuchniewicz · 2026-07-13T17:25:08Z

+    let config_path = project_resources_directory_path.join("config.ini");
+
+    // --- 3. Determine runtime load mode (dylib vs in-process) ---
+    // Decide how to load the runtime (dynamic library or in-process).


Suggested change

// Decide how to load the runtime (dynamic library or in-process).

JDuchniewicz · 2026-07-13T17:25:29Z

+fn run_app() -> Result<()> {
+    // --- 1. Detect project directory, run layout, and hot-reload mode ---
+    // In the development build, standalone will look for the resource files in the "res" directory of the pill project directory
+    // In the release build, "res" directory is copied to /build/release/data/res (TODO: pack all resources use by pill project into a single data file)


Is this task tracked somewhere?

JDuchniewicz · 2026-07-13T17:26:53Z

+    let runtime_load_mode = parse_runtime_load_mode(std::env::var("PILL_RUNTIME_MODE").ok())
+        .or(in_process.then_some(RuntimeLoadMode::InProcess))
+        .unwrap_or(if cfg!(target_os = "macos") {
+            RuntimeLoadMode::InProcess


This hints that macOs does dynamic library loading differently? Am I correct?

JDuchniewicz · 2026-07-13T17:34:58Z

+
+/// Returns true when the engine workspace's Cargo.toml lists the given
+/// project directory name as a workspace member.
+fn workspace_includes_project(


While I like having a bulletproof system - do we need all these shenaningans? Sounds a bit like - try X,Y,Z and mash it with a hammer until it works. Shouldn't be have an elegant solution and expect our devs to apply it? We also can allow for "do whatever the heck you want" but this comes at much higher maintenance cost.

JDuchniewicz · 2026-07-13T17:44:37Z

+    engine_source_directory_path: Option<&Path>,
+    name: &str,
+) -> Vec<PathBuf> {
+    let mut candidates = vec![build_data_directory_path.join(paths::dylib(name))];


again, quite expensive operations that might slow down hot-reloading significantly.

JDuchniewicz · 2026-07-13T17:59:57Z

+                if trimmed.starts_with("members") && trimmed.contains('[') {
+                    in_members = true;
+                }
+                if in_members && !inserted && trimmed == "]" {


this code is duplicated, maybe a further commonalization pass could be handy here? I noticed several other such similar/duplicated functions - could you take a closer look and eliminate those?

JDuchniewicz · 2026-07-13T18:21:17Z

+
+/// Build project + pill_native + pill_runtime via cargo in the engine workspace.
+/// Copies the standalone executable and dynamic libraries into the output directory.
+/// Supports --features, hot-reload, PlantUML pre-rendering, --headless, and per-project target dirs.


duplicated verbose comment with the one above

JDuchniewicz · 2026-07-13T18:22:26Z

+        cargo_command.env("CARGO_TERM_COLOR", "always");
+    }
+
+    let mut cargo_child = if use_experimental_logs_parser() {


I don't get the reason for using an experimental log parser

Is this because we want to parse the logs for failures for CI?

JDuchniewicz

Some minor changes and cleanups necessary. Otherwise looks very solid and well-thought through. Good job 👍🏽

Seeing the end of the big-refactor tunnel (pill_tunnel) already 💊

MattSzymonski added 30 commits June 21, 2026 22:59

Rework

f729faf

Cleanup project structure

0d56089

Fix critical issues?

13faf4b

Fix high prio issues

ff48d00

Fix low prio

8f1e969

Update comments

bc44137

Cleanup

10914d0

Cleanup

dd1603c

Cleanup

185616f

Update devops

86742d6

Change files layout

988b6e7

Slim launcher

72f1ee6

Fix misc

67361b5

Remove NO_PATH placeholder from workspace members

1297ac1

Fix duplicate closing bracket in workspace members

560ab1d

Rework ci, rename game to project, cleanup examples

294bed1

Merge remote-tracking branch 'origin/main' into devops_rework

ff2992e

Cleanup examples

698c632

Test launcher

d58dba9

Fix flags and hot reload

a45ecf6

Fix wasm build

d78800a

Remove crashing drop

dc298cf

Remove empty example

b728437

Refactor native

d376d1f

Cleanup

263ae04

Cleanup hot-reload

8d06541

Cleanup build and rebuild logging

30493aa

Improve comments

69d3b96

Fix wasm builds

0415cd2

Fix basic tests

c2ee3dc

JDuchniewicz reviewed Jul 13, 2026

View reviewed changes

JDuchniewicz requested changes Jul 13, 2026

View reviewed changes

Fix tests

d85e282

	let args = if let Some(ctx) = runtime_context {
	let args = if let Some(context) = runtime_context {

Uh oh!

Conversation

MattSzymonski commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pill Launcher Refactoring

CI Pipeline Overhaul

New: Build Size & Performance Benchmarks

Examples & Templates

Naming: Game → Project

Documentation added:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JDuchniewicz left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

MattSzymonski commented Jul 3, 2026 •

edited

Loading