Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[recipe testing strategy] Testing recipes on a weekly basis #2346

Open
remi-kazeroni opened this issue Oct 15, 2021 · 1 comment
Open

[recipe testing strategy] Testing recipes on a weekly basis #2346

remi-kazeroni opened this issue Oct 15, 2021 · 1 comment

Comments

@remi-kazeroni
Copy link
Contributor

Is your feature request related to a problem? Please describe.
During the meeting on the recipe testing strategy #2259 on October 14, 2021, we discussed the possibility to test some recipes more frequently than shortly before a release. These tests would be done on a weekly basis for a subset of recipes. This testing approach would help to check if changes in the Core affect the recipes. Several options were discussed to this end:

  • In order to limit the computational efforts required, we would need to find a sensible way to split recipes in subsets. Would it make sense to run recipes that are known to fail or problematic more often than others? Shall the recipes with a too long runtime be excluded from this testing approach?
  • What kind of computational resources would be needed for that? Are the resources available with the ESMValBot enough?
  • Is it possible and relevant to perform this testing without calling the diagnostic scripts?
  • How do we handle the "missing data problem"? And do we need to test data changes as well? What about the availability of observational data?
  • Would it help to have a "test version" of each/many recipes that could be computationally less demanding, possibly using less datasets and a narrower time range? That would imply twice more recipes to maintain.
  • Could we develop synthetic data on which all recipes would run? Consensus was reached that developing such dataset would be difficult as ESMValTool runs on a great variety of data. These data may also not capture the trends and thresholds analyzed in recipes.
  • Could the recipes be tested using a very low resolution only? Not clear if that would work for all recipes.
  • Should we define a better way to record backwards incompatible changes such as a "live changelogs"?

Feel free to edit this summary or to comment in this issue. (This issue could be transferred to the Core if more appropriate.)

@bouweandela
Copy link
Member

Created ESMValGroup/ESMValCore#1636 to describe work done on using a special set of small recipes for testing ESMValCore.

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

No branches or pull requests

2 participants