Dear Bas,
Il 27/03/26 13:29, Sebastiaan Couwenberg ha scritto:
On 3/26/26 7:34 PM, Sebastiaan Couwenberg via Pkg-grass-devel wrote:
The CI pipeline for this change is failing repeatedly.
The build on i386 succeeds which suggests that we should skip
test_Sentinel1SarProduct more broadly to not get the test killed, on
my local system with more resources than Salsa CI the test succeeds.
I think we should skip it also when CI=true is set in the environment
as done by GitLab CI, or maybe even unconditionally.
What are your thoughts?
I've got a patch now that skips the test on 32-bit architectures or when
less than 8 GB memory is available.
The Salsa CI runners have less than 8, and the GitHub Actions runners
have 16 GB total which explains why the test doesn't get killed there.
I'm looking at it right now.
The problem should be only linked to "SLC" products for which a kind
mosaic of performed internally via `xarray.concat`.
Apparently the use of such function is currently no lazy (although it
could, see [1]) so the entire dataset is materialized in memory.
Luckily if dask is available the computation is still done in a lazy way.
My suggestion is to add dask as build dependency (only for testing).
It should hopefully solve the memory erro in CI.
I'm going to make a test on my fork.
[1] https://github.com/pydata/xarray/issues/4628
cheers
--
Antonio Valentino
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
