[CI Github Actions] Update (outdated) actions versions that produce Node.js warnings #2411
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2411 +/- ##
=======================================
Coverage 94.51% 94.51%
=======================================
Files 246 246
Lines 14020 14020
=======================================
Hits 13251 13251
Misses 769 769 ☔ View full report in Codecov by Sentry. |
|
Would it make sense to run the actions to check that they all work? |
|
a good idea, bud! |
|
well I'll be a monkey's uncle - OSX is failing miserably - seems there is an issue with masked values of esmf regridding, looking at the esmf build it's different than previously (though the version is the same, just the build hash differs - BTW such an old version!) - I'll investigate tomorrow - good call to run the tests here, bud! |
|
ahahaa! I figured out what the problem is: compare an env that passes vs an env that fails for the same OSX job for the same Python 3.11: the one that passes is from last night's test (nightly), and the failed one is the one from here, so minimal time difference between them - most of the dependencies (if not all!) have the same version, same conda channel (conda-forge) but almost all of them have different build hashes - that's because the new miniconda setup grabs the that's not entirely wrong since the machines are indeed ARM64: but the problem is that I am not entirely sure we have actually made our package run on an ARM64 with dedicated ARM64 dependency builds, do you know @bouweandela ? I'd err on the caution side and restrict the OSX deps to |
|
this is actually flagged at setup-miniconda GH conda-incubator/setup-miniconda#344 - they recommend using macos-13 and pin to v3- which is blergh |
|
I found out that forcing the Intel architecture as: osx:
runs-on: "macos-latest"
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11"]
architecture: ["x64"]
fail-fast: false
name: OSX Python ${{ matrix.python-version }}
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: conda-incubator/setup-miniconda@v3
with:
architecture: ${{ matrix.architecture }}
activate-environment: esmvalcore
environment-file: environment.yml
python-version: ${{ matrix.python-version }}
miniforge-version: "latest"
miniforge-variant: Mambaforge
use-mamba: trueworks biutifully even with the ARM64 processor and v4, well at least for now, before they diverge completely 🥳 |
|
OK @bouweandela everything works again 🍺 |
|
All recent Macs have an arm processor, so wouldn't users install the arm version of the packages by default? I think we should test the situation our users are in. Has the problem with the arm build of esmf already been reported? If arm builds really don't work, we would need to add some extra instructions on how to install to our osx installation instructions. |
|
Indeed, but this is a decent patch - it still uses the arm processor snd osx 14, it only switches the packages to be generic osx64, which are still compatible with the arm architecture, when they stop being compatible, it's anyone's guess. The problem with our failed tests with arm64 builds is most probably from netCDF4 or even deeper from hdf5 - I need to investigate, but it's not easy since I don't have access to an M1 Mac (I have a couple ye olde Intel Macs only). For M1 users it's easy - all they have to do is build the env with generic osx64 built dependencies 🍺 |
How? |
a man of many words you are, bud 🤣 They use the x86 64bit installer from https://docs.anaconda.com/free/miniconda/ instead of the arm one - this is exactly what the GH action does too via setting the |
|
Cheers @bouweandela 🍺 |
Description
Three of our actions use outdated versions, therefore one sees a long list of warnings on the action's front page - the problem with oudated actions is that there will be fewer and fewer nodes that actually support them, so that means either run delays or even worse: the RR word (run rejection, don't get any other ideas, like Rolls Royce 😆 )
Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.
To help with the number pull requests: