Add Windows ARM64 support to CI

[chinazhangchao]

Hi @dvarrazzo , I'm from Microsoft and recently I'm working on improving Python ecosystem support for Windows on Arm.
So I updates the CI workflows to add support for Windows ARM64 builds and tests. Could you please help to review? Thanks.

Test results:
https://github.com/chinazhangchao/psycopg2/actions/runs/32325062129

Windows ARM64 support and workflow updates:

• Updated the windows job in .github/workflows/packages.yml to add win_arm64 to the build matrix, conditionally select the appropriate runner image, and exclude unsupported Python versions for ARM64.
• Modified PostgreSQL setup in the workflow to install it only if not present, accommodating the lack of PostgreSQL on Windows ARM64 runners.
• Adjusted environment variables and paths to use the correct vcpkg triplet (arm64-windows for ARM64, x64-windows-release for AMD64) and set CIBW_ARCHS_WINDOWS accordingly. [1] [2]

Build script improvements:

• Updated scripts/build/wheel_win32_before_build.bat to set VCPKG_TARGET_TRIPLET based on architecture and install the correct libpq package for each triplet.

Stub script enhancements:

• Enhanced pg_config_vcpkg_stub to support both AMD64 and ARM64, checking the platform and triplet, and constructing the vcpkg path dynamically. The documentation was also updated to reflect the new usage. [1] [2]

[ndabas]

@chinazhangchao Skipping tests would be a bad idea. You can install PostgreSQL on the WoA runners like I have done in this PR: psycopg/psycopg#1385

[chinazhangchao]

Hi @dvarrazzo @michaelknap

Could you please help to review? Thanks.

Chao
Microsoft

[michaelknap]

Hi @dvarrazzo @michaelknap

Could you please help to review? Thanks.

Chao Microsoft

Is there a reason for using PostgreSQL 17 on Windows ARM when the existing Linux test jobs use postgres:16? If PostgreSQL is only a test fixture, should the ARM job use a pinned PostgreSQL 16 package for consistency, or is the additional PostgreSQL 17 coverage intentional?
If the Chocolatey fallback is intentionally retained, I would also harden the Windows job:

• set job-level permissions: contents: read;
• set persist-credentials: false on actions/checkout;
• pin the exact Chocolatey package version and source;
• add --require-checksums;
• check $LASTEXITCODE immediately after Chocolatey and throw on failure, so subsequent PowerShell commands cannot mask a failed installation.

This job builds and uploads wheels, so its downloaded dependencies and failure behaviour should be deterministic.

That being said, I am not a maintainer of psycopg2 so I would wait for @dvarrazzo to confirm.

[chinazhangchao]

Hi @dvarrazzo @michaelknap
Could you please help to review? Thanks.
Chao Microsoft

Is there a reason for using PostgreSQL 17 on Windows ARM when the existing Linux test jobs use postgres:16? If PostgreSQL is only a test fixture, should the ARM job use a pinned PostgreSQL 16 package for consistency, or is the additional PostgreSQL 17 coverage intentional? If the Chocolatey fallback is intentionally retained, I would also harden the Windows job:

• set job-level permissions: contents: read;
• set persist-credentials: false on actions/checkout;
• pin the exact Chocolatey package version and source;
• add --require-checksums;
• check $LASTEXITCODE immediately after Chocolatey and throw on failure, so subsequent PowerShell commands cannot mask a failed installation.

This job builds and uploads wheels, so its downloaded dependencies and failure behaviour should be deterministic.

That being said, I am not a maintainer of psycopg2 so I would wait for @dvarrazzo to confirm.

Thanks for the detailed review. PostgreSQL 17 was not intentional, so I aligned the Windows ARM64 job with the existing PostgreSQL 16 test fixture. The Chocolatey package is now pinned to postgresql16 version 16.15.0 and the community repository source, with checksum enforcement and immediate failure checking. I also restricted job permissions to contents: read and disabled persisted checkout credentials.