I think involving ZFS is more complicated and system dependent than it needs to be. We should start storing the last N buildbot builds anyway, instead of always overwriting. Linking to a slightly older build from the download page should not be a problem then.
On Mon, Aug 12, 2019 at 8:08 PM Dan McGrath <[email protected]> wrote: > > Hi, > > On Mon, Aug 12, 2019 at 8:00 AM Brecht Van Lommel <[email protected]> > wrote: > > > The idea would be to have a flow like this for example. I think it > > would help to get better quality reports, or to help users find > > solutions themselves in some cases. > > > > https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/edit#bookmark=id.83ndneimph3m > > > Regarding the "Buildbot" section from the above Google doc: > > > It would be good if a serious bug is introduced, we have an easy way to > > pin the buildbot download page to an earlier version without that bug until > > it is fixed. > > > Actually, this could potentially be possible using ZFS snapshots. The > directory is already available to the jail itself, so it would be a matter > of just rsync'ing back over the current contents of the download directory > -- which is what the PHP script enumerates, IIRC -- with the contents of > one of the snapshots. This could be done by had, or programatically, as > needed. Of course, the downside to merely rsync'ing back over top of the > current files, is that the next build bot run will replace the files again, > but this could possibly be the easiest to implement a "temp fix" by just > sym linking the broken file(s) to their /.zfs/snapshots/ alternative, > submitting the patch in advance, and then letting the next buildbot run > replace it. Not exactly the best solution, when you don't have strict > control to prevent builds from rolling out, mind you. > > I would suggest at least creating a dataset in ZFS for just those files, > and modifying the current site to use symbolic links to point to an > alternate location, for as long as is needed. This might require some > tweaks to the PHP file that we use now (to ensure it follows the sym link), > but I don't see why this couldn't work. It also has the benefit of not > requiring extra permissions to the jail itself, just a one time creation of > a new dataset. > > There is also the possibility of allowing for the ZFS dataset to be > manipulated from within the jail itself, thus allowing a script to say, > create or delete snapshots on the download directory, but I would generally > recommend against this, at least with the current design that we have for > jail configuration. > > > Cheers, > > Dan > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
