BUG - GLOWS integration tests fail in CI

[jtniehof]

Description of the issue

The GLOWS integration tests are failing when run automatically against PRs, e.g. #190. It's a failed bind mount, probably something to do with setting up the environment to run.

Steps to reproduce the issue

No response

Expected vs Actual behavior

No response

Code Snippet (If applicable)

The traceback is painful but the actual relevant bit appears to be:

----------------------------- Captured stdout call -----------------------------
Built docker container: sha256:400130e850d6ec118ea3b0d6808d737cd840e69167ade5b644b6099f295d0986
----------------------------- Captured stderr call -----------------------------
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/runner/work/imap_L3_processing/imap_L3_processing/temp_cdf_data

Additional notes, affected areas, and suggested fixes

No response

[jtniehof]

This also fails OMM:

uv run --with pytest pytest tests/integration/test_glows_processor_integration.py
[snip]
-------------------------------------------------------------------------------------------- Captured stdout call --------------------------------------------------------------------------------------------
Built docker container: sha256:eec24ce8eb75571180e05903f11e18312f4967e7faea7709cb2a9526641d1e62
-------------------------------------------------------------------------------------------- Captured stderr call --------------------------------------------------------------------------------------------
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/jtniehof/scm/imap_L3_processing/temp_cdf_data

So it's a matter of the integration test being tightly tied to the development environment.

[pleasant-menlo]

I suppose the test expects the "temp_cdf_data" directory to exist, but it's not in the repository and there is nothing that creates it in the environment outside of the Docker container. Perhaps run_test_in_docker should ensure both that and "run_local_input_data" exist before attempting to bind them.

By the way, a couple of the GLOWS "integration tests" take a very long time to run to completion (on the order of an hour) because they make a large number of L3e files. It would be helpful to figure out how to limit the scope if we are requiring them as part of CI.

• Peter

[jtniehof]

Thanks Peter. That was sufficient information for me to realize this is much easier than I thought!

If I just mkdir temp_cdf_data in the top of the repo, all but one of the tests passes. The error is:

======================================================================
ERROR: test_run_glows_l3be_against_prod (tests.integration.test_glows_processor_integration.TestGlowsProcessorIntegration.test_run_glows_l3be_against_prod)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tests/integration/test_glows_processor_integration.py", line 53, in decorated
    test_to_run(self)
  File "/tests/integration/test_glows_processor_integration.py", line 512, in test_run_glows_l3be_against_prod
    shutil.copy(test_reprocessing_file, AncillaryFilePath(test_reprocessing_file.name).construct_path())
  File "/usr/local/lib/python3.12/shutil.py", line 435, in copy
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/local/lib/python3.12/shutil.py", line 262, in copyfile
    with open(dst, 'wb') as fdst:
         ^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/run_local_input_data/glows_l3bcde_prod/imap/ancillary/glows/imap_glows_force-reprocessing-config_20250101_v000.csv

mkdir -p run_local_input_data/glows_l3bcde_prod/imap/ancillary/glows/ is sufficient to get the last test to run...having just run_local_input_data present isn't. So we can maybe make some updates in run_test_in_docker or in the workflow config.

I'm not too worried about how long these take, because we're not requiring successful tests to merge...they're just informative. Still might be worth a little tweaking, just not high priority.

[jtniehof]

The last test does fail with mean_time: NO_SUCH_VAR: Named variable not found in this CDF while making the l3b JSON from the l3b CDF for the l3d input. This is probably not surprising and we can check it again when all the GLOWS updates are deployed and reprocessed.