Am Sonntag, den 23.02.2020, 12:04 +0100 schrieb Han-Wen Nienhuys: > On Sun, Feb 23, 2020 at 11:55 AM Jonas Hahnfeld < > [email protected] > > wrote: > > > But a CI should test the changes in every possible way we care about - > > exactly because "this change cannot possibly break". And here I really > > mean CI to be integrated into tooling and running without human > > interaction, just as Patchy is right now. And if somebody needs to > > build a new image every few days to have an updated ccache, that's > > something that should be clearly weighted against the benefits IMO. > > If you can automatically run a CI job, you could automatically run a > seeding job.
This sounds contradicting to me: Either you want to use the ccache for multiple jobs or you're running it for every commit - not gaining anything except for increased complexity. > In practice, I think we would have to have a mechanism (git tags?) by > which we can annotate that a certain release changed the regtest > output. Assuming we have those often enough, that takes care of > reseeding the cache. And that's where the infrastructure comes into play: Assuming that all of this is to happen automatically, it will get pretty hairy from what I've seen so far. Sure, all of this is possible, but at what cost? > Note that the test baseline takes as much space as the cache, so it's > not going to make a huge difference by not having them. It does: complexity. From what I've seen in the last months, some things in LilyPond are overly complicated. I'm not saying that there are easy solutions to all problems, but I don't think a more complex setup helps in this case. Jonas
signature.asc
Description: This is a digitally signed message part
