@Fabien-Chouteau Since not all gits have the same default, or the same way of specifying the default, I think we have to choose something and set it. Might as well be master, unless we want to be explicit and use e.g. alr_tests.

Oh.

My tests ran on macOS 11.7 with Xcode 13.2.1, yours ran on 12.6 (which is the version I run on here) and Xcode 14.0.1 (I’m running 14.1.0). Other than that I don’t see a difference.

The difference between 14.0.1 & 14.1.0 was a missing symbol in libunwind - I think we’d have seen it?

They’re supposed to run on macos-latest - what’s going on?

I think we’d have seen it?

Yes, this is the same situation we are seeing in recently opened PRs. What I see is that in our self-build the linking fails, and that in the test suite, stdout seems to be silenced, so we only get either empty output or stderr output. I've not yet tried to diagnose further, I'm a bit overloaded at the moment.

About the linker error, people here are mentioning an Xcode bug that is being worked on by Apple. Workaround would be to downgrade to Xcode 13.4.

Could the other issues, the testsuite ones be related to gnatW8?

About the linker error, people here are mentioning an Xcode bug that is being worked on by Apple. Workaround would be to downgrade to Xcode 13.4.

Or to upgrade to 14.1 (this is the current release: the 14.0 version was the one with the problem that I came across to do with exception handling).

I think it may be possible to change to 14.1, but we’d have to fix on macos-12 rather than macos-latest? Some older discussions here.

Could the other issues, the testsuite ones be related to gnatW8?

I had an issue; git submodule update failed with missing revision in ada-toml, fixed by going to dep/ada-toml and checking out the right commit. But this meant instant build failures.

I think we may have a way ahead.

This run failed because of a change I made to "fix" a problem I saw in misc/local-reject-origin (is it invalid property: origin or invalid property: 'origin'?) but aside from that I saw 213 out of 214 passes!

I am doing a run on macos-10.15 it seems to work as well. So the question is, do we want the latest or the oldest?

This patch:

diff --git a/.github/workflows/ci-macos.yml b/.github/workflows/ci-macos.yml
index dacfeb8b..74d4f752 100644
--- a/.github/workflows/ci-macos.yml
+++ b/.github/workflows/ci-macos.yml
@@ -1,6 +1,7 @@
 name: CI macOS
 
 on:
+  push:
   pull_request:
     paths-ignore:
       - 'doc/**'
@@ -18,6 +19,11 @@ jobs:
     runs-on: macos-latest
 
     steps:
+    - name: Set up Xcode
+      uses: maxim-lobanov/setup-xcode@v1
+      with:
+        xcode-version: latest-stable
+
     - name: Check out repository
       uses: actions/checkout@v2
       with:

if it ends up running on macos-12 chooses Xcode 14.1, on macos-11 it chooses Xcode 13.2.1. In both cases the tests run without the massive set of errors we’ve been seeing.

(you’ll note I’ve added on: push: to make my initial tests quicker).

How to proceed? (particularly with the maxim-lobanov action).

My preference would be to go to macos-10.15 and avoid introducing an external action. @mosteo do you have an opinion?

My preference would be to go to macos-10.15 and avoid introducing an external action. @mosteo do you have an opinion?

I think this would be a bad idea because 10.15 will be unsupported from 1 December.

Nothing wrong with macos-11, is there? it’s just the chance of getting macos-12 with the bad Xcode that’s worrying.

If we do that, we can drop this PR. Who knows how other OS/git combos will behave?

Normally I would also prefer an older release than an external action, but if the unsupporting is going to catch up to us soon, I guess for a while until the bug is fixed is OK to use it.

This had fallen through the cracks, sorry.