Skip to content

Conversation

@maflcko
Copy link
Member

@maflcko maflcko commented Sep 30, 2025

Currently, the cross-compiled exe files for Windows are tested in CI on a native Windows VM. However, the same is not done for the cross-compiled macOS executables.

This will add about 17 minutes of additional sequential CI delay, and I am not sure if it will ever catch an issue.

So leaving as draft for now.

@DrahtBot DrahtBot added the Tests label Sep 30, 2025
@DrahtBot
Copy link
Contributor

DrahtBot commented Sep 30, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33509.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK katesalazar, hodlinator

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #32380 (Modernize use of UTF-8 in Windows code by hebasto)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@maflcko maflcko changed the title ci: Check macos-cross ci: Check macos-cross executables on macOS Sep 30, 2025
@katesalazar
Copy link
Contributor

Concept ACK

Copy link
Contributor

@hodlinator hodlinator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK d40e61e

It feels more complete to test something closer to what the end user will be running (although we are still not using Guix builds).

Since we don't have high hopes of this actually detecting any issues that the rest of the CI would not have found, seems to make more sense as a nightly job?

Runs fine:
https://github.com/bitcoin/bitcoin/actions/runs/18132888148/job/51606766678?pr=33509

@maflcko
Copy link
Member Author

maflcko commented Oct 6, 2025

Since we don't have high hopes of this actually detecting any issues that the rest of the CI would not have found, seems to make more sense as a nightly job?

Thx, done in #33549 and https://github.com/maflcko/b-c-nightly/actions/runs/18282485376/job/52056370818

@maflcko maflcko closed this Oct 6, 2025
@maflcko maflcko deleted the 2509-ci-mac-cross branch October 6, 2025 15:06
@fanquake
Copy link
Member

fanquake commented Oct 8, 2025

It's not completely clear to me why we should have cross tests for Windows, but not for macOS, regardless of how-likely we think they are to find issues (or the runtime). Putting things in nightly repos also increases the likelyhood of double-handling changes, to fix things later (also assuming they are reported).

Since we don't have high hopes of this actually detecting any issues that the rest of the CI would not have found, seems to make more sense as a nightly job?

@hodlinator could you elaborate on this? Why do we think the rest of the CI would detect issues in the cross-compiled binaries, if the other macOS CIs are using a different compiler, dependencies, build logic, SDK etc?

@maflcko
Copy link
Member Author

maflcko commented Oct 8, 2025

I just wonder if there ever was a single issue found if this was run in the CI in the past.

If this has never found an issue, the overhead doesn't seem worth it:

I can understand the desire to test as much as possible, but it will never be possible to test everything, so we'll have to accept and decide where to stop.

I'd say any platform config that exposes less than 1 issue per year should not be added to the main CI, but I am happy to hear other thoughts.

@hodlinator
Copy link
Contributor

Broadly agree with maflcko. Despite WSL (not sure of the status of that on CI), Windows is overall less similar to Linux than macOS is to Linux, so it is probably more likely to uncover issues.

I guess the downside of nightly is that figuring out which commit introduces a failure lands on build-oriented people. Until we learn CI to git bisect. So assuming that CI-cost is low, I can see how this PR may be preferable. Maybe there's a middle ground of only running upon merge into master?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants