Test/document version support, miscellanous

[wpbonelli]

Hi, thanks for the action. I have a few changes on a fork and wondered if you might be interested in pulling any upstream:

• expand CI test matrix across runner OS and gcc versions
• test runner compatibility daily (sample run)
• add runner/gcc version compatibility table to README
• add CI badge to README
• replace soon-deprecated set-output mechanism with GITHUB_OUTPUT file
• use Chocolatey to install mingw on Windows (considering caching this...)
• add msys* and cygwin cases for detected platform (can be returned by uname -s on Windows)
• test pwsh (Powershell Core), powershell (Powershell Desktop) and cmd on Windows
• link to libgfortran-5.dll on Windows (avoid missing DLL issues)
• link to older gcc lib paths on Mac (avoid missing *.dylib issues)
• inline setup step, source platform-specific functions from setup-fortran.sh

Also saw the note on supporting the Intel toolchain — currently accomplishing this with modflowpy/install-intelfortran-action, perhaps something could be merged here? It would be nice to have one action for GNU or Intel fortran compilers. (It's now possible to cache files and update environment variables in composite actions.)

[wpbonelli]

Fixed CI continue-on-error config so jobs stay green even if runner/toolchain are incompatible (sample run). Also added a mechanism to detect compatibility changes — the compat job diffs the compat.csv generated by the test matrix with one stored in the repo (if any), and a PR is opened into the default branch to update the CSV and README if changes are found (example)

[wpbonelli]

Looks like CI may have failed due to restrictions on the automatically provided GITHUB_TOKEN. I've updated the compat job with write permission on PRs and repo contents as documented here.

I'm not sure this will pass in this PR however, as the link above states the maximum access level for forks is read. To succeed, the workflow may need to be triggered by a branch or event associated with this repo rather than my fork.

[awvwgk]

You can exclude the update step from pull requests, it only makes sense to change the README on a push event.

[wpbonelli]

Happy to try Intel support here or a separate PR, if you still have that in mind. Could select just C/C++ and Fortran components from the HPC kit to reduce download size — the action could minimally guarantee C/C++/Fortran compilers for either toolchain?

[awvwgk]

For the Intel installation the installation procedure provided in spack might be useful: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/intel-oneapi-compilers/package.py. There seem to be offline installers for the individual components of the toolkits which can be used here.

If that PR is ready, I would go ahead and merge it. Support for Intel compilers is best done in a separate PR.

[wpbonelli]

Ok, will look into Intel/spack in a separate PR.

I think this one is ready. A bot update PR is expected on merge, as the CSV I checked in is currently empty. After that it should only update if compatibility changes.