Containerize GCC & Intel CI workflows - #1158
Conversation
|
@BrianCurtis-NOAA putting this here for discussion/proof of concept for containerizing workflows beyond NCEPLIBS. |
|
In practice it looks like the repo-level caching for the oneAPI compilers only saves about 15-20 seconds, so, it may or may not be worth the cache space with respect to the 10GB limit. |
|
@AlexanderRichert-NOAA I assume this method allows for easy upgrading to newer versions as needed? Is there a way to tell the total space it's using in our 10GB limit? |
|
That's the idea behind the commented block about modifying the Spack installation. We could try it out here if maybe you have an example of a package that gets updated frequently. I don't think GitHub directly reports the total usage, but you can basically look under https://github.com/ufs-community/UFS_UTILS/actions/caches and add everything up (if this PR were merged, I think it would just be the Intel installation; conceivably in the future test files could get cached there as well, or in the container images). |
|
@AlexanderRichert-NOAA I think this is the way forward, do you need to check/do anything else before merging? |
|
No, I think this is good. If I don't hear from you sooner I'll check in in a month or so just to see how it's going and if there are any lingering issues. |
DESCRIPTION OF CHANGES:
This PR containerizing the GCC and Intel CI workflows based on the containers generated by https://github.com/NOAA-EMC/ci-common-build-cache.
Note: I haven't looked yet at precaching test files, either in the UFS_UTILS container images or through the Actions cache.
TESTING
PR CI runs successfully with updated workflows (including CTest & installation).
DEPENDENCIES:
none
DOCUMENTATION:
Workflows are internally documented with comments, including links to https://github.com/NOAA-EMC/ci-common-build-cache documentation.
LINKED ISSUES: