@dzelge the units tests from GH action don't run because they use the xcube Python env (renamed to "cate-env"). This will use latest xarray 0.19.0 and with this, the xcube code fails.
This is different from the Docker build, where we use the actual Cate environment and then installl xcube and xcube-cci into it.
Three options
fix and relase xcube for xarray 0.19
pin xarray <0.19 in Cate
fix unit tests actions to use same approach as in Docker build
Completed deprecation of passing an xarray.DataArray to Variable() - will now raise a TypeError (PR5630)
EDIT
I'm wrong, both Docker and GH actions call mamba env update -n cate-env on an existing conda-env. However, this will cause xarray and Dask be pushed up to latest version making my fix ineffective. Not sure whether we should really call mamba env update because it will also remove any packages that are not in the environment.yml used to update. At least this is true for conda update (I always hated that).
@dzelge the units tests from GH action don't run because they use the xcube Python env (renamed to "cate-env"). This will use latest xarray 0.19.0 and with this, the xcube code fails.
This is different from the Docker build, where we use the actual Cate environment and then installl xcube and xcube-cci into it.
Three options
Or some combi.
EDIT
Test failure is due to xcube code in
xcube.core.normalize.normalize_missing_time()(obviously we neglected former xarray warnings). See http://xarray.pydata.org/en/stable/whats-new.html#deprecations:Completed deprecation of passing an xarray.DataArray to Variable() - will now raise a TypeError (PR5630)
EDIT
I'm wrong, both Docker and GH actions call
mamba env update -n cate-envon an existingconda-env. However, this will cause xarray and Dask be pushed up to latest version making my fix ineffective. Not sure whether we should really callmamba env updatebecause it will also remove any packages that are not in theenvironment.ymlused to update. At least this is true forconda update(I always hated that).