Skip to content

Conversation

@ceholden
Copy link
Collaborator

@ceholden ceholden commented Feb 10, 2026

What I am changing

Adds workflow for Landsat tile

How I did it

  • Landsat tile
    • Added Asset, Tasks, and Workflow
    • Make downloading vs copying from local dir conditional
  • Base
    • added common type def for type hinting
    • save asset data in context using Asset as key (prevent overwrite if the 'key' is the same)
  • early dev ride-alongs,
    • conditionally upload (default=true) Landsat AC data
    • forward $@ to pytest from test script
    • Landsat AC tasks use common typedef

How you can test it

scripts/test

@ceholden ceholden marked this pull request as ready for review February 10, 2026 23:31

def test_create_manifest(mock_binaries: Path, mock_config: EnvConfig) -> None:
"""Test surface reflectance manifest creation."""
output_basename = f"HLS.L30.T{MGRS}.2020001T101010.v2.0"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be configured (i.e., v2.0) as a parameter instead of hard coded for future HLS v3 productions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 this could be refactored, though I don't think it'll have benefit for a v3 since I would hope we can delete a lot of these tasks as our overall workflow becomes simpler (e.g., avoiding having like 7 format translations from TIF -> binary -> TIF -> HDF -> HDF -> COG)

Funny enough a lot of the other HLS code is still referencing v1.5 ^_^. As with the code in those other projects, the version here doesn't really matter for the purpose of the test

s3.create_bucket(Bucket=BUCKET_OUT)
s3.create_bucket(Bucket=BUCKET_GIBS)

granule_id = f"HLS.L30.T{MGRS}.2020001T101010.v2.0"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious why it is being hardcoded here for date '2020001T101010'? Is it something that can be configured using 'MOCKED_SCENE_TIME'?

Probably the docstrings of the function can be further enhanced to better explain what specific behavior is being tested (beyond just "generation").

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the docstrings of the function can be further enhanced to better explain what specific behavior is being tested (beyond just "generation").

Generally -1 to this sort of comment, especially for tests. If the test code isn't straightforward enough to serve as the source of truth, then it's more likely that variable names are unclear, the scope of the test is too large, or some of the test setup could be refactored.

Writing a long paragraph explaining what the code does is not a great use of time. Especially over time as the code changes it's common for such lengthy documentation to become out of date, making it misleading and worse than if it didn't exist

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious why it is being hardcoded here for date '2020001T101010'? Is it something that can be configured using 'MOCKED_SCENE_TIME'?

We could be using MOCKED_SCENE_TIME here, but it doesn't really matter for this test.

The bigger problem is that this has a hard coded date instead of using the date value from mock_config. I'll fix that

assert cfg.working_dir.exists()


def test_download_pathrows(mock_config: EnvConfig, mock_aws_s3: S3Client) -> None:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be beneficial to have an error handling for this function to test handling of missing input files or server errors, etc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error handling for this function

Assuming you mean for the DownloadPathRows task, +1 this is a good idea! One caveat is right now there is no error condition in the task itself for something like missing input files.

In the original shell script there was no error checking for the equivalent step. We would just download whatever we found, and any errors associated with incomplete outputs would rise up later in the pipeline. This sort of error would be confusing, since the actual issue happened in previous steps

I think we might be able to check if we have all the expected data and raise an error at the appropriate time (during the download task)



def process_path_rows(mock_binaries: Path, mock_config: EnvConfig) -> None:
"""

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docstrings could be further improved

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there something specific that is unclear about the code or the single line docstring? Typically tests are self explanatory and don't require extensive docstrings

If anything this test is missing the test_ prefix to the function, so pytest probably isn't recognizing it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants