-
Notifications
You must be signed in to change notification settings - Fork 18
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
Add a minimal test of entire workflow and run it continuously #56
Comments
Here's a list of things that need to be solved (sorted by severity) so that we have a 100% automatic, low data, low runtime workflow test:
The first point (capacityfactors) is by far the worst. When we solve the issues in the list above, all other steps should be very fast, especially when we limit the geographic scope. |
Agreed that we need this, but limiting scope also creates issues with not picking up some of the more annoying elements of the workflow that we probably want to be testing (e.g. handling Kosovo, filling missing load data, getting ISO vs. EU country codes, assigning plants to basins when they don't fall in one). I can see a different geographic region being needed to catch each of these... |
You are right. Still, any error that is caught by CI is good. So just because the CI test wouldn't catch all errors doesn't mean it's useless. We can also apply an hierarchical approach: a simplified workflow that is run very often, and a full workflow that is run less often. |
We have a similar issue for the estimation of solar and wind potentials. The discussion over there is relevant here, too. |
Bryn mentioned in the dev call today that data caching is possible on GitHub runners. |
A continuous integration test would catch errors early. For that, the workflow must be 100% automatic and we should have a configuration that requires minimal downloads and minimal runtime. We can then use a simple GitHub action that runs Snakemake with this configuration (example).
The text was updated successfully, but these errors were encountered: