I propose we merge together the 25 workflows for a given year into a single workflow representing the tests for the whole year.
The tests will take the same amount of time to complete, as there will be 25 jobs all running in parallell inside the single workflow.
Drawbacks
All jobs/tests will run for all days always, even if just a single day has been changed.
We will only get 1 status badge on the README.md page, instead of 25 status badges - one for each day - giving us less "badge-resolution".
Advantages
We circumvent the limit Github puts on free accounts to only be able to run 20+ workflows in parallel, by running 20+ jobs in parallel instead.
Less diff - Adding a new year becomes less noisy, as only 1 more workflow-file needs to be added, instead of 25 files. Also only 1 badge needs to be added - less diff in README.md.
Less overhead - Running 25 jobs is potentially less overhead, takes less time to execute, than running 25 workflows with a single job.
Conclusion
I think that this PR gives us a good sweet spot, making it easier for us to maintain the workflow files, but still giving us quick feedback running the tests, because tests for all days will still run in parallel and the first job/day that fails will fail the entire workflow/year.
Proposal
I propose we merge together the 25 workflows for a given year into a single workflow representing the tests for the whole year.
The tests will take the same amount of time to complete, as there will be 25 jobs all running in parallell inside the single workflow.
Drawbacks
Advantages
Conclusion
I think that this PR gives us a good sweet spot, making it easier for us to maintain the workflow files, but still giving us quick feedback running the tests, because tests for all days will still run in parallel and the first job/day that fails will fail the entire workflow/year.
Changelog
.github/workflows/2020.yaml.github/workflows/2021.yamlExpected behaviour