Add macOS to CI test matrix

[Johnosezele]

This pull request addresses issue #877 by adding macOS to the CI test matrix. This will help catch platform-specific bugs in the future.

[spacebear21]

We need to consider that this triples the number of Test actions that need to run for each workflow (3 rust toolchains x 3 OSes). I don't know what our Action Runner limits are, or how these OSes vary in performance, but we should keep those in mind.

[coveralls]

Pull Request Test Coverage Report for Build 17923076448

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 84.744%

---

Totals
Change from base Build 17920764384:	0.0%
Covered Lines:	8560
Relevant Lines:	10101

---

💛 - Coveralls

[Johnosezele]

We need to consider that this triples the number of Test actions that need to run for each workflow (3 rust toolchains x 3 OSes). I don't know what our Action Runner limits are, or how these OSes vary in performance, but we should keep those in mind.

I did a bit of research about this, rust projects like ripgrep uses scheduled testing for the full matrix, and reqwest tests stable on all platforms, MSRV only on Linux.

Maybe we could try a tiered approach:

• Run essential check: tests on stable Rust with ubuntu-latest only.
• On merges, we run the full tests on stable across ubuntu-latest, macos-latest, and windows-latest.

[Johnosezele]

The failing CI checks on the new macOS and Windows runners is due to the linux specific flock command. For Pr #886 where I used mkdir locking will fix this.

[nothingmuch]

We need to consider that this triples the number of Test actions that need to run for each workflow (3 rust toolchains x 3 OSes).

It more than triples, unfortunately: https://docs.github.com/en/billing/managing-billing-for-your-products/about-billing-for-github-actions#minute-multipliers

I don't know what our Action Runner limits are, or how these OSes vary in performance, but we should keep those in mind.

https://docs.github.com/en/actions/reference/actions-limits#storage-limits-for-all-github-hosted-runners

that last link is very confusing since it talks about storage but seems to implicate minutes per month, and it seems we're over that limit:

https://github.com/payjoin/rust-payjoin/actions/metrics/usage

but we also use way less than say bitcoin core or ldk, so i think it must be the wrong link

[nothingmuch]

hmm, public repos don't seem to fall under the free tier limits, so if this is true then i don't think there's a problem, but we should verify from some authoritative source so that we don't end up unable to run the basic tests:

https://github.com/orgs/community/discussions/26054

[spacebear21]

I think we can keep this simple and less wasteful by keeping the toolchain matrix as-is for linux, and only run the test suite on the stable toolchain for macOS/Linux.

[Johnosezele]

macOS CI Test Failures

Unit Test Error

When running only unit tests on macOS, I encounter:
error[E0432]: unresolved import crate::send::v1
--> payjoin/src/core/send/v2/session.rs:107:22
|
107 | use crate::send::v1::SenderBuilder;
| ^^ could not find v1 in send

Integration Test Failures
When running the full integration test suite on macOS, I encounter:

Test Failures (6 failed tests)

failures:

---- integration::multiparty::ns1r stdout ----
thread 'integration::multiparty::ns1r' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

---- integration::v2::test_bad_ohttp_keys stdout ----
thread 'integration::v2::test_bad_ohttp_keys' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

---- integration::v2::test_err_response stdout ----
thread 'integration::v2::test_err_response' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

---- integration::v2::test_session_expiration stdout ----
thread 'integration::v2::test_session_expiration' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

---- integration::v2::v1_to_v2 stdout ----
thread 'integration::v2::v1_to_v2' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

---- integration::v2::v2_to_v2 stdout ----
thread 'integration::v2::v2_to_v2' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.15.0/src/clients/cli.rs:46:39:
Failed to execute docker command: Os { code: 2, kind: NotFound, message: "No such file or directory" }

test result: FAILED. 7 passed; 6 failed; 1 ignored; 0 measured; 0 filtered out; finished in 15.67s
error: test failed, to rerun pass -p payjoin --test integration

Unit Test Issue: Missing v1 module in send module
Integration Test Issue: Docker not available on macOS GitHub Actions runners

[benalleng]

To get docker on MacOS CI you will need to manually include it

rust-payjoin/.github/workflows/python.yml

Lines 89 to 91 in a5d82d1

	- name: Setup Docker on macOS
	uses: douglascamata/setup-docker-macos-action@v1.0.0

[Johnosezele]

To get docker on MacOS CI you will need to manually include it

rust-payjoin/.github/workflows/python.yml

Lines 89 to 91 in a5d82d1

	- name: Setup Docker on macOS
	uses: douglascamata/setup-docker-macos-action@v1.0.0

CI hit this:
Detected M-series processor runner without nested virtualization support, exiting.

Edit:
using macos-12 instead of macos-latest (which is M-series) bypassed this

[benalleng]

Lets use macos-13 as this is still supported in the setup-docker-macos-action, as well its what we are already using in our python CI for consistency
https://github.com/douglascamata/setup-docker-macos-action?tab=readme-ov-file#currently-supported-public-runner-images

[spacebear21]

Perhaps this PR should wait on #915 which will remove the docker dependency entirely. Currently the macOS docker CI step is very slow and error-prone (Docker setup step took 5min in this recent run https://github.com/payjoin/rust-payjoin/actions/runs/16723381144/job/47332768078, and appears to be hanging in the CI for this PR).

[nothingmuch]

it should be possible to rebase this on the redis PR to see if that fixes things

[benalleng]

With the update from #989 and the lessons learned about macos builder I think it is ok for us to use macos-latest after #915 is merged

[benalleng]

This is no longer blocked as of 92a3154

[spacebear21]

I'm partial towards closing this as wontfix per #877 (comment) but don't feel strongly about it.

[Johnosezele]

With the update from #989 and the lessons learned about macos builder I think it is ok for us to use macos-latest after #915 is merged

@benalleng macos-latest causes the Continuous integration / Stable tests on macOS (pull_request) to fail, reason I pushed again without it.

[benalleng]

I'm partial towards closing this as wontfix per #877 (comment) but don't feel strongly about it.

I'd like to at least see what is actually added to the CI time/flow without any docker stuff before making a decision here

[benalleng]

With no caching it sits at 7 minutes, while this is too long right now I would like to see the time reduction with caching

[spacebear21]

Re-ran that job, it took 3 min with cache hit which is ~1 min (50%) longer than on the ubuntu runner

[benalleng]

Since this is no longer blocked, the actual differences between the ubuntu and macOs runners on the payjoin crate just don't seem large enough to justify a new runner. Which now is the longest runner in the payjoin crate atm.

Especially with the docker and redis dependency gone these runners are mostly identical, any differences that come about like perhaps a new dependency failure on macOs or ubuntu would quickly become apparent by our devs.

I think macos CI makes some sense in FFI where we actually want to test generated binaries, but for the core library i'm not convinced it's really useful other than testing bash scripts that we run locally all the time anyway

-spacebear