Sfink/Thought Experiment - One Minute Builds: Difference between revisions

Line 82: Line 82:
That leaves just a few problems: (a) the try server may not have done a build close enough to the desired one for its cache to be useful, (b) the ccache would be ridiculously big and burn insane amounts of bandwidth, and (c) the ccache data might take too long to get copied over to the m-c build slaves and so would not be available when needed.
That leaves just a few problems: (a) the try server may not have done a build close enough to the desired one for its cache to be useful, (b) the ccache would be ridiculously big and burn insane amounts of bandwidth, and (c) the ccache data might take too long to get copied over to the m-c build slaves and so would not be available when needed.


==== (a) Build bits must be relevant ====
==== (a) Prebuilt bits must be relevant ====


(a) is not a problem if the developer rebased to m-c before doing the try build. These days, that's not a safe assumption. So either we enforce changed behavior (eg don't allow an m-c submission if the base is too old), or we automate it by making the try server do the rebase itself. The latter is tempting -- in fact, if we really only want the build from one architecture/configuration, then you could leave the try server job scheduling as-is except add in a separate "rebase build" that did the automatic rebase for that single arch. That has the added benefit of notifying the developer when a rebase might not work automatically and might require some manual intervention. To be fancy, you'd also prevent the m-c submission until that build was complete.
(a) is not a problem if the developer rebased to m-c before doing the try build. These days, that's not a safe assumption. So either we enforce changed behavior (eg don't allow an m-c submission if the base is too old), or we automate it by making the try server do the rebase itself. The latter is tempting -- in fact, if we really only want the build from one architecture/configuration, then you could leave the try server job scheduling as-is except add in a separate "rebase build" that did the automatic rebase for that single arch. That has the added benefit of notifying the developer when a rebase might not work automatically and might require some manual intervention. To be fancy, you'd also prevent the m-c submission until that build was complete.
Confirmed users
328

edits