I don't have any hard numbers timing a destroy && up cycle but my seat of the pants inclination would be that the initial apt-get update takes much more time than $IP/maintenance/install.php.

Vagrant 1.8's new vagrant snapshot command might really go a lot farther towards improving speed for a typical destroy && up testing cycle. Vagrant 1.8 is also now using linked clones for VM images which is intended to reduce both disk usage and time needed for creating new VMs.

Thanks.

Yeah, the suggestion is not motivated by avoiding install.php. It's rather mainly about APT package downloads, and apt-get update to a certain extent.

vagrant snapshot will definitely be helpful for various scenarios (once I upgrade to 1.8).

It can also solve the "avoid repeated base downloads" case if there is a named snapshot with no roles.

If we did do a base box, I'm think it shouldn't even have MediaWiki installed, just Debian packages. That would allow testing early phases of provisioning, e.g. DB creation.

In T123005#1927011, @dduvall wrote:

I like this idea. The clone of core is also a lengthy process but I'm not sure how to integrate that into the base box without having to move it to the nfs/vboxsf mount upon the first provision (which might be a little ugly).

Also, while time-consuming, the clone of core and extensions is a one-time thing. It doesn't need to be redone every destroy/up cycle.

The goal is to make the Debian packages also a one-time thing.

Producing a custom base image like this could also help with things like T161707: Upgrade linux kernel used on Vagrant to 4+.