PDAF-updates

[jjokella]

Includes:
HPSCTerrSys/pdaf#24
HPSCTerrSys/pdaf#21
HPSCTerrSys/pdaf#20
HPSCTerrSys/pdaf#10
HPSCTerrSys/pdaf#18
HPSCTerrSys/pdaf#19
HPSCTerrSys/pdaf#16
HPSCTerrSys/pdaf#17
HPSCTerrSys/pdaf#15
HPSCTerrSys/pdaf#9

[jjokella]

@kvrigor There is an error in the eCLM-PDAF build, because the CI-compilation is stricter than the Intel-compilation I check PDAF updates with (which is a good additional check).

My idea is now to have earlier warnings of such errors, by running the CI on branches dev-pdaf-* (which I use for updating PDAF without making them a PR in TSMP2).

I added this:

TSMP2/.github/workflows/CI.yml

Lines 4 to 8 in 5db6838

	on:
	push:
	branches: [ master, dev-pdaf-* ]
	pull_request:
	branches: [ master, stages-2025-pdaf ]

However, I only need eCLM-PDAF to be run. Is there a simple way to restrict CI on dev-pdaf branches to just eCLM-PDAF? The other builds would be a waste of resources, I guess.

[kvrigor]

However, I only need eCLM-PDAF to be run. Is there a simple way to restrict CI on dev-pdaf branches to just eCLM-PDAF? The other builds would be a waste of resources, I guess.

I think the cleanest way is to remove the eCLM-PDAF steps in CI.yml and move them to a new job file called .github/workflows/PDAF.yml. Then you can freely apply build triggers specific to your branches without affecting the main CI job. As for eCLM-ParFlow-PDAF, we can keep it in CI.yml for simplicity to avoid duplicating ParFlow dependency installation across jobs.

[jjokella]

To avoid duplication, I would for now then stick with running the full CI on the dev-pdaf-* branches!