We need a policy/script/magic doodad for new input data on every merge request

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

So, we have a difference in input data in REMIND that stems from mrremind (and associated packages) versions 70 days/18 merge requests apart.
We can't reproduce data for the individual merge requests, due to irreversible changes since then.
Considering the mrremind debug marathon two weeks ago, I strongly suggest we do something™ to automatically produce new input data on every new version of the mrremind package.
The computational cost should be low, as results are cached and subsequent input data production will be faster. Since people should test their commit anyway, the cost should actually be only one round of puc aggregation.
The benefit for finding mrremind bugs early, and being able to trace REMIND input data bugs without jumping through hoops, is potentially immense.
Opinions, @fbenke-pik?

[fbenke-pik]

I agree, we should set this up. Lavinia, any doubts or concerns?

I can look into this an hopefully set it up until end of next week (i.e. 14th april, due to some other urgent tasks, i cannot tackle this right away). Hope that is soon enough?

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Hope that is soon enough?

It's an investment for the future. Won't help us with existing problems anyhow, and I don't expect many problems this could help with being created over the Easter holidays. ;)

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

As the bug kicking this off turned out to be in mrdrivers [↑], I suggest to implement this for all packages we care about.

[LaviniaBaumstark]

generating input data for ALL PRs in any mr* package involved in the input data generation might be a bit too much/often. For now we will add input data generation to the weekly test runs.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

generating input data for ALL PRs in any mr* package involved in the input data generation might be a bit too much/often.

That is a quantitative assessment?
Happy debugging then …