I can confirm this works with the current changes in CLIMADA-project/climada_python#839

Thanks for checking!

After merging CLIMADA-project/climada_python#839, the pipeline still fails. These are the errors:

=========================== short test summary info ============================
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestReader::test_cross_antimeridian - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestReader::test_from_file_pass - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestReader::test_set_one_pass - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestReader::test_tcr - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestReader::test_two_files_pass - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_rainfield.py::TestModel::test_rainfield_diff_time_steps - TypeError: get_close_centroids() missing 1 required positional argument: 'buffer_km'
FAILED climada_petals/hazard/test/test_tc_surge_bathtub.py::TestTCSurgeBathtub::test_cross_antimeridian - AssertionError: 1.3178962188473244 != 0.0
=========== 7 failed, 144 passed, 694 warnings in 170.62s (0:02:50) ============

I don't really understand how these come about because the buffer_km argument is given in these instances 🤔

I don't really understand how these come about because the buffer_km argument is given in these instances 🤔

This is exactly the kind of error that we get when working with the version of get_close_centroids before the changes in CLIMADA-project/climada_python#839 because the number of positional arguments has changed. How often is Jenkins checking out new versions of the core develop branch when running unit tests for petals? Maybe it's only checking out once per day or so?

@emanuel-schmid, how often is the Core updated in the Petals pipeline?

how often is the Core updated in the Petals pipeline?

Depends - usually it is up to the develop branch. But since release 4.1 it is pinned to 4.1.0 (from pypi), hence: not. The idea was to make the transition to 5 smoother.

Ah, I was not aware that this had already taken effect. Is there a way to parameterize this? So that, e.g., one may set the Core version in one of the Jenkins scripts to make sure that a branch of Petals works with the particular target version of Core? We would just need something like

pushd climada_python  # Not sure where this lies on Jenkins
git pull
git checkout <tag/branch>  # Enter target branch here
pip install -e ./
popd

This wouldn't be safe, unless we had a virtual environment for each branch. Having a persistent conda environment for each branch is not feasible given the limited space on the server. Having a temporary environment for each branch is not ideal because of the building costs. Maybe a venv environment on top of the conda environment could be a solution or manipulating the PYTHONPATH. I'm going to look into these.

True, we would manipulate the persistent environment. It should not be long until we merge the Centroids update, so I think this is not urgent. I wanted to give the GitHub Actions for Petals a shot anyway, maybe I can solve it there. This way, we can keep the Jenkins pipeline as is.