CI: Update some deprecated dependency versions

[Gadgetoid]

Notably bumps Python to prevent macOS builds failing, and bumps "checkout" and "setup-python" versions to avoid deprecation warnings.

Tests/builds still seem to be failing so I've also enabled "continue-on-error" to try and make it run all the tests - for a better picture of what's failing and where- but seem to have failed to make this work across both MicroPython and CircuitPython tests.

[Gadgetoid]

I believe the CircuitPython builds failing is due to an oversight in how the custom config supplied via MP_CONFIGFILE is handled. shared/timeutils/timeutils.h imports mpconfigport.h explicitly, causing some duplication errors between the default config and the custom config.

Edit: Ookay that's not even the only file circumventing the logic in mpconfig.h 😬 - https://github.com/Gadgetoid/circuitpython/commit/3ae6ed78afedb7f4a8dadca35628e1626c8ff99a

[Gadgetoid]

Okay after some helpful feedback from tannewt, it looks like MP_CONFIGFILE is a vestigial non-feature that cannot be relied upon in CircuitPython.

The good news, however, is that aiui sed -e '/MICROPY_PY_UHASHLIB/s/1/0/' < circuitpython/ports/unix/mpconfigport.h > circuitpython/ports/unix/mpconfigport_ulab.h did nothing, because MICROPY_PY_UHASHLIB does not appear in unix/mpconfigport.h. Adding a commit on to test this assumption seems to get CircuitPython CI up and running again.

The last hurdle:

2 tests failed: cholesky logspace
\nFAILURE cholesky.py
--- cholesky.py.exp 2024-06-03 22:44:06
+++ cholesky.py.out 2024-06-03 22:44:06
@@ -5,5 +5,5 @@
        [-1.0, 1.0, 3.0]], dtype=float64)
 array([[4.242640687119285, 0.0, 0.0, 0.0],
        [5.185449728701349, 6.565905201197403, 0.0, 0.0],
-       [12.72792206135786, 3.046038495400855, 1.649742247909068, 0.0],
-       [9.899494936611665, 1.624553864213789, 1.849711005231386, 1.392621247645583]], dtype=float64)
+       [12.72792206135786, 3.046038495400855, 1.649742247909066, 0.0],
+       [9.899494936611665, 1.624553864213789, 1.849711005231389, 1.392621247645579]], dtype=float64)

I ... am not qualified to know what might have caused this difference in these specific cases. Perhaps the laws of natural physics shifted slightly, the wind direction changed, someone patched a CPU vulnerability or some mysterious and wonderful nonsense affected floating point precision enough to throw these out of whack. Possibly just a fix-the-tests issue?

[v923z]

@Gadgetoid Philip, many thanks for getting to the bottom of this! I would just let it pass for now, and I can fix the single test case that's causing the problem.