github automated tests use deprecated features that will be disabled soon

[SamuelTrahanNOAA]

The github automated tests for UPP are generating warnings about features that will soon be disabled. This comes from the steps with "cache" in their names:

Warning: The save-state command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

[WenMeng-NOAA]

@AlexanderRichert-NOAA How could these warnings be addressed? I also saw total cache storage hits limit at
https://github.com/NOAA-EMC/UPP/actions/caches
Should I manually clean up some caches? Thanks!

[AlexanderRichert-NOAA]

I think the warnings are due to the usage of a relatively old version of the GitHub cache action. Maybe try "@V3" instead of "@v2"?

[WenMeng-NOAA]

@SamuelTrahanNOAA Could you test the fix @AlexanderRichert-NOAA suggests in your PR #646? Thanks!

[SamuelTrahanNOAA]

I changed all of the @v2 to @V3 in .github/workflows/intel.yml and pushed the change.

[SamuelTrahanNOAA]

Apparently it needs to be @v3 (lower-case)

[SamuelTrahanNOAA]

Now I'm seeing new errors from the UPP build:

 ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `dlopen@GLIBC_2.34'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `fstat64@GLIBC_2.33'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `dlerror@GLIBC_2.34'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `stat64@GLIBC_2.33'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `dlclose@GLIBC_2.34'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libnetcdf.so: undefined reference to `fstat@GLIBC_2.33'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `dlsym@GLIBC_2.34'
ld: /home/runner/work/UPP/UPP/spack/var/spack/environments/upp-env/.spack-env/view/lib/libhdf5.so.310: undefined reference to `lstat64@GLIBC_2.33'

[SamuelTrahanNOAA]

https://github.com/NOAA-EMC/UPP/actions/runs/4297640315/jobs/7490914467

[AlexanderRichert-NOAA]

It's a bit of a shot in the dark, but you might try adding sudo mv /usr/local/ /usr_local_mv to the beginning of the build-upp step. If that doesn't do it then I have no idea.

[SamuelTrahanNOAA]

When I do that, it can't find cmake:

/home/runner/work/_temp/649064c1-568f-4abe-8877-a61c4eee5d65.sh: line 8: cmake: command not found

[AlexanderRichert-NOAA]

That's strange, since in the setup we ran "sudo apt install cmake". You could maybe try installing it through Spack. In any case, I think what's going on is that it's picking up on glibc's under /usr/local which shouldn't be getting used, so I think you'll need to find some way to get those out of the way (I suppose you could do something like rm $(find /usr/local/ -name '*libc*') but that seems awfully involved). You could also try adding sudo apt install cmake to the beginning of the build step to see if the problem is that it's not getting saved in the cache.

[SamuelTrahanNOAA]

I'd rather merge the fixes we have now that do work and let the maintainer of this test suite fix the problem.

[WenMeng-NOAA]

@SamuelTrahanNOAA Thanks for testing. Yes, I will process the final tests and work with @AlexanderRichert-NOAA for residual CI issue.

[edwardhartnett]

GitHub is frequently deprecating versions of various actions, but the actions don't stop working. So I would suggest not worrying too much about warnings of the CI system for YML code.