CI: add dev-only Windows smoke workflow

[kad-link]

Description

This PR adds an experimental Windows CI workflow to provide a lightweight signal for Windows contributors.

• Adds windows-ci.yml running on windows-latest for push and pull request
• Runs flake8 on Windows (same lint target as Linux CI)
• Runs python -m compileall as a smoke check to catch syntax or import-time issues
• Marked as non-blocking via continue-on-error: true

Note

This workflow is intentionally dev-only and does not attempt a full nominatim-db install on Windows (blocked by PyICU/ICU native build requirements on GitHub-hosted runners). Linux CI remains the authoritative test pipeline.

Future Work

This is the first step toward full Windows support. I am planning a follow-up effort to resolve the PyICU / ICU native build issues so we can eventually run full Nominatim installs and tests on Windows CI.

[Copilot]

Pull request overview

This PR introduces an experimental Windows CI workflow to provide early feedback for Windows contributors without blocking merges. The workflow runs lightweight smoke tests including linting and Python compilation checks.

Key Changes

• Adds a new non-blocking Windows CI workflow that runs on push and pull request events
• Executes flake8 linting to verify code style consistency across platforms
• Runs Python compileall as a smoke test to catch syntax and basic import issues early

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The inline comment is missing a space after the hash symbol. According to standard YAML comment formatting conventions, there should be a space between the # and the comment text.

Suggested change

	continue-on-error: true #this is a smoke test (experimental); it won't block merges
	continue-on-error: true # this is a smoke test (experimental); it won't block merges

[lonvia]

That's a nice start but we'll need a full run of Nominatim's tests to make sure that the installation actually works. At a minimum the tests workflow should work just like on the Linux installations. Ideally, we get a install workflow to work as well.

[kad-link]

That's a nice start but we'll need a full run of Nominatim's tests to make sure that the installation actually works. At a minimum the tests workflow should work just like on the Linux installations. Ideally, we get a install workflow to work as well.

Thanks for the feedback.
To spread this further in an organized way, I would like to approach this in stages (with one PR per stage) to keep things maintainable and reviewable.

Stage 1 : (Windows Test Parity)

• Setup PostgreSQL on Windows
• Build the required Python environment
• Run the same Python unit tests and BDD tests that currently run on Linux (or as close as possible, skipping only where Windows-specific blockers exist)

Stage 2 :

Add full import support + osm2pgsql so that BDD import scenarios run successfully.

Stage 3 :

Replicate the full install workflow on Windows to match Linux install validation.

I’ll start with Stage 1 so we can first get reliable test coverage on Windows and iterate from there.
Please let me know if this plan aligns with expectations.

[lonvia]

Restricting CI tests to the Python unit tests in a first stage PR sounds reasonable. Lets start with that.

[kad-link]

Restricting CI tests to the Python unit tests in a first stage PR sounds reasonable. Lets start with that.

Hi @lonvia , while going through the current ci-tests.yml , I noticed the create-archive job which prepares the source tarball and later consumed by subsequent jobs (including Python unit-tests).
Since I am working on adding CI coverage for Windows, I am wondering if it should be implemented in the CI for Windows too. Since create-archive is only packaging the source tree , I think it would be reasonable to keep this job running on Linux, while the other jobs run on Windows. Linux runners seem well suited for shell-based packaging steps.

So, could you kindly clarify these 2 issues in summary ?

• Should the Windows CI workflow include the create-archive job?
• If so, is it preferred to keep the create-archive job Linux-only (while the rest of the code Windows-specific), or should there be a Windows-specific implementation for the create-archive job too?

[lonvia]

The create-archive job just downloads the additional country data, making sure that this is only done once. There is no need to duplicate this job on Windows. Simply make your job depend on this one and use the created artifact in the same way the Linux jobs do.

[kad-link]

The create-archive job just downloads the additional country data, making sure that this is only done once. There is no need to duplicate this job on Windows. Simply make your job depend on this one and use the created artifact in the same way the Linux jobs do.

Just a small query here, by using the same artifact, do you mean to create the Windows CI coverage in the existing file itself (ci-tests.yml ) ?or make another file for Windows CI ?
If a separate file, then artifact can't be shared and it has to be written again right?