Fix up UWM testing logic in automated builds

[AlexanderRichert-NOAA]

Right now, test_ufswm.sh requires using a fork of ufs-weather-model in order to point to the modules to be tested. We should be able to use some search-and-replace on the modulefiles so that we can use the head of develop in the authoritative repo.

[climbfuji]

Fixed.

[AlexanderRichert-NOAA]

@rickgrubin-noaa where does this happen in the weekly build scripts as far as pointing ufs-weather-model to the new modules?

[rickgrubin-noaa]

@rickgrubin-noaa where does this happen in the weekly build scripts as far as pointing ufs-weather-model to the new modules?

The setting for BRANCH handles differing modules without having to change automation scripts.

[AlexanderRichert-NOAA]

The idea here is to be able to point test_ufswm.sh to the ufs-weather-model head of develop and have it run with the newly installed modules on any system. Re-opening the issue.
I think the approach here is to either have our weekly build logic build UWM modulefiles for a given system, or, probably more simply, do a search-and-replace on the path, and set appropriate environment variables to set each package version.

[rickgrubin-noaa]

The idea here is to be able to point test_ufswm.sh to the ufs-weather-model head of develop and have it run with the newly installed modules on any system. Re-opening the issue. I think the approach here is to either have our weekly build logic build UWM modulefiles for a given system, or, probably more simply, do a search-and-replace on the path, and set appropriate environment variables to set each package version.

test_ufswm.sh does point to ufs-weather-model@develop by default. Not setting any env variables would "run with the newly installed modules" on a system.

To me, it seems more work to modify scripts or CI/CD, but that said, no worries, as you see fit.