The release binaries for Apple Silicon macOS (arm64-apple-darwin
) have been available since v23.0.
It seems reasonable to add a task for such a platform to CI. Also it would prevent regressions like bitcoin/bitcoin#24958.
The release binaries for Apple Silicon macOS (arm64-apple-darwin
) have been available since v23.0.
It seems reasonable to add a task for such a platform to CI. Also it would prevent regressions like bitcoin/bitcoin#24958.
A native macOS task does not aware of Linux container settings, and it
does not use the `depends_built_cache`.
Would this actually prevent #24958? Wouldn’t it silently “fail” green?
It will fail due to https://github.com/bitcoin/bitcoin/blob/f7a1e676d536115aba649672ba1e68755a1c90dc/configure.ac#L1751-L1757
Not sure if it makes sense to run this check on every commit. There is some probability of breaking that is acceptable and unavoidable. I think we should focus on checks that are likely to catch errors often enough to be a net-positive considering the maintenance overhead and CPU overhead of the added CI task.
So if #24958 is the only known bug this prevents, I tend toward NACK, even though the code looks good and correct.
I expect that there are ppl running M1 locally, but if not, this could also be implemented as a nightly task to run outside this repo.
9@@ -10,10 +10,10 @@ if [[ $QEMU_USER_CMD == qemu-s390* ]]; then
10 export LC_ALL=C
11 fi
12
13-if [ "$CI_OS_NAME" == "macos" ]; then
14+if [ "$CI_OS_NAME" == "macos" ] && [ -n "$PIP_PACKAGES" ]; then
15 sudo -H pip3 install --upgrade pip
16 # shellcheck disable=SC2086
17- IN_GETOPT_BIN="/usr/local/opt/gnu-getopt/bin/getopt" ${CI_RETRY_EXE} pip3 install --user $PIP_PACKAGES
18+ IN_GETOPT_BIN="$(brew --prefix gnu-getopt)/bin/getopt" ${CI_RETRY_EXE} pip3 install --user $PIP_PACKAGES
328+ CI_USE_APT_INSTALL: "no"
329+ PACKAGE_MANAGER_INSTALL: "echo" # Nothing to do
330+ FILE_ENV: "./ci/test/00_setup_env_mac_native_x86_64.sh"
331+
332+task:
333+ name: 'macOS 12 native Apple Silicon [gui, system sqlite] [no depends]'
CPU overhead of the added CI task
I don’t think the M1 CPU time is shared with any other task.
According to https://cirrus-ci.org/faq/#are-there-any-limits there is a limit of “12.0 CPUs macOS VM (1 VM)”, so it will be shared with the other macos instance?
It looks like docs are a bit inconsistent after introducing Apple Silicon support.
They are correct about x86_64
:
But M1 limits differ:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
Updated f2e07bdbac58c2cd38cd5f668847e95cde3eeefd -> 84cfbc7329e92191e391ba5bb1991108229bbb51 (pr25160.02 -> pr25160.03, diff):
I am still wondering how many bugs this will catch that are not found by other tasks.
I hope every bug on the macOS arm64
platform, which has a steadily growing number of users, will be caught before release.
I hope every bug on the macOS arm64 platform, which has a steadily growing number of users, will be caught before release.
It only caught one bug for now, which doesn’t seem enough to justify the maintenance burden? Note that in this repo, *bsd, s390x, various linux distros, valgrind, … aren’t tested either.