ci: add cross-platform smoke tests for Windows and macOS #28

Activity

1. utsab345

   added

   help wantedExtra attention is neededExtra attention is needed

   testingTests and test coverageTests and test coverage

   CIContinuous integration and workflowsContinuous integration and workflows

   on Oct 20, 2026
2. Abhishekpandey123-git commented on Oct 20, 2026

   

   Abhishekpandey123-git

   on Oct 20, 2026

   More actions

   Hi maintainers,

   I'm interested in contributing to issue #28, “CI: add cross-platform smoke tests for Windows and macOS.”

   Before starting implementation, I'd like to confirm whether this issue is still available and whether you have any preferred approach for the smoke tests, CI matrix, and package validation.

   I also noticed the GSoC-related context and want to make sure my contribution aligns with the project's expectations.

   Thanks!
3. utsab345 commented on Oct 20, 2026

   

   utsab345

   on Oct 20, 2026

   OwnerAuthor

   More actions

   Hi @Abhishekpandey123-git, thanks for your interest in contributing! Issue #28 is still open and available.

   Suggested approach:

   • Add a separate smoke-test job using a matrix with windows-latest and macos-latest in .github/workflows/ci.yml. Keep the existing Linux job unchanged.
   • Start with smoke tests only: install the package, run stepfork --version, and test a basic trace save/load round trip. There is no need to run the full test suite on every operating system initially.
   • Reuse the existing uv-based setup and installation steps where practical. Leave the existing Linux matrix and other workflows intact.
   • Document any platform-specific limitations, such as differences in signal-based timeout behavior, where relevant.

   This issue is a standalone CI improvement and is not tied to GSoC.

   Please share your proposed workflow changes here before starting a substantial implementation, and leave another comment when you begin so we can coordinate.

   Thanks again. Looking forward to your contribution!
4. how2how2how2-arch commented on Oct 25, 2026

   

   how2how2how2-arch

   on Oct 25, 2026

   Contributor

   More actions

   Proposed change before I open a PR, since the issue asks for the workflow shape first.

   Shape: one new smoke job in .github/workflows/ci.yml, leaving test untouched.

   • runs-on: ${{ matrix.os }} over macos-latest and windows-latest, Python 3.11 and 3.13 (lowest and highest per requires-python). The middle version stays on the Linux matrix — that is a cost choice, not equal coverage. Say if you want 3.12 on the new OSes too; it doubles the job count to 6.
   • Steps: uv sync --locked, then stepfork --version and stepfork --help through the console script rather than the in-process runner (the entry point is what actually breaks on a new OS), then pytest tests/unit/test_storage.py tests/unit/test_cli.py -q.
   • Those two files are the whole "installation + CLI startup + trace save/load" surface the issue names: test_storage.py saves and loads traces under tmp_path, test_cli.py covers help/version/no-command. Both are fast — 28 tests in 0.46 s on the machine below — and neither needs the network.
   • The full suite, ruff, mypy and uv build stay where they are. No existing step is modified: the diff is additions only.

   Local evidence I can actually produce: this machine is macOS arm64. Running the exact commands above here: stepfork 0.2.1 from --version, --help exits 0, and 28 passed in 0.46s. I have no Windows machine, so the Windows half is unverified by me until CI runs it once — that is the point of the job.

   One limitation I found while checking whether the job would be green, worth deciding on separately. The committed bundles under examples/ and tests/golden/ carry SHA-256 digests over file bytes (trace/integrity.py::_hash_file, export/receipt.py::bundle_digest), but the writers in trace/storage.py open in text mode without newline="" (write_text, and path.open("w") for events.jsonl). Consequences:

   • a bundle written on Windows contains \r\n, so the same trace does not reproduce a digest recorded on Linux;
   • on windows-latest, git's default core.autocrlf=true rewrites those committed files to CRLF at checkout, before any test runs;
   • there is no .gitattributes in the repo.

   So a Windows job that read those bundles would fail for a reason unrelated to installation. That is why the subset above is narrow and touches no committed bundle. The fix — newline="" on the writers and/or a .gitattributes with eol=lf — changes the on-disk format contract, so I would rather it be its own change with its own test than smuggled into a CI PR. Happy to do it next if you agree.

   Opening the PR for the workflow now so the Windows question gets an actual answer instead of an argument.