Run 2 build batches when both compiler and targets.json are updated simultaneously

[felipesanches]

At #45 (comment) @cmyr said:

for another example of why I might some input on when these are merged is to avoid having the new targets land at the same time as a big patch in fontc, which would obscure whether or not the changes we see on the dashboard are related to source changes or compiler changes :).

Could we perhaps make the system trigger twice in cases like this? In other words, queue running the build using the updated compiler version first and once that's done, do it again with the new compiler and the updated targets data set. That way, no data points would end up being masked out as you described.

[cmyr]

It's possible but it would require rewriting a bunch of stuff. The logic that checks if we should run (which checks if the inputs are new, as well as if the fontc rev has changed) runs after we've pulled fontc and updated the targets repo. Because fontc_crater lives in the fontc repo, and because we do want to always be running the latest fontc_crater it would be tricky to separately run an older fontc.

Doing what you describe would require a more complicated orchestration process that maintained a run queue, and did independent tracking of relevant changes and updates. Maybe this would be nice eventually, but I'm not sure the ROI is there quite at the moment, when it is pretty easy to just manually make sure we merge these updates when there aren't any new changes in fontc.