The purpose is to set up Linux (Ubuntu) build environment in Docker. This obviates the need of setting up VirtualBox using Vagrant.

This seems like a sizable change without any clear benefit. Instead of setting up VirtualBox/Vagrant you'd have to set up Docker, so what do you gain? Closing as WONTFIX unless there's a clear benefit to switching.

This is a good reminder I haven't posted the (limited) notes from the Searchfox sessions at the all-hands, apologies.

I'd discussed this with Subhamoy at/around one of the sessions in the context of difficulties both others and I had had in terms of getting vagrant running on OS X and on an Ubuntu box that I moved from virtualbox to libvirt. Things improved a lot with https://github.com/mozsearch/mozsearch/commit/cc3c4b3fcf223cb6191857fa9e95c6e51dc2aa4e#diff-23b6f443c01ea2efcb4f36eedfea9089 and https://github.com/mozsearch/mozsearch/commit/a94cba4125fab4443feda2b404e94feddb2da2ce#diff-23b6f443c01ea2efcb4f36eedfea9089 which fixed actual correctness problems with VirtualBox.

I'd characterize the problems as:

• VirtualBox has been historically flakey and unreliable for me on linux with short reads everywhere. Honestly, I don't think it was that bad on OS X other than a very ill conceived attempt on my part to use homebrew. Once I nuked homebrew things weren't that bad (after the Vagrantfile fixes).
• The libvirt situation is much improved, but I ran into real dependency/bit-rot problems on setting things up on Ubuntu 19.10 on my laptop. I had followed the https://github.com/vagrant-libvirt/vagrant-libvirt#installation instructions on my desktop for 19.04 and that worked fine and upgraded to 19.10 fine. But for a fresh install on 19.10 on my laptop, vagrant plugin install vagrant-libvirt ran into all kinds of ruby dependency mismatches. I ended up just trying to install everything via apt and that worked and what is currently documented, but I think that's using the libvirt plugin which I believe is different from the vagrant-libvirt plugin, with the former I believe being unmaintained.

And for the general solution space, all we really want is an Ubuntu machine with our provisioning shell scripts run on it, so we're not particularly tied to any virtualization system, we just want to minimize the hassle for potential contributors.

I'm going to reopen this since I'm notionally mentoring this and I think it makes sense to have a tracker for such an investigation. I absolutely agree that actually landing such a change or recommending use of docker depends on the set of changes seeming reasonable and maintainable. I know Subhamoy ran into some troubles related to bazel and building livegrep, and that would be an example of a potential blocker if we no longer had the potential to fork livegrep as necessary.

And marking that Subhamoy is currently pursuing this, but if anyone else out there has tried to get a Searchfox VM going and had trouble with the existing options and wants to try Docker, do chime up on this bug!

Thanks for providing the additional context! I generally do dev on macOS and haven't really seen any issues with vagrant so this would be pretty low priority for me personally. But if other people want to do the migration to docker and feel it would help with ease of development, then feel free :)

Andrew, should we keep this?

I think it makes sense to keep this bug for tracking and for interested parties as I've continued to hear and infer that the effort required to create a Searchfox virtual machine continues to be the largest stumbling block to Searchfox contributions. But I am dropping the priority to P5 for now to convey that it's not likely to be prioritized to happen on its own unless someone interested volunteers. I continue to be happy to help mentor anyone looking to pursue this, noting that I've successfully used docker in the past but am not an expert and my help would be more on the searchfox side of things.

In https://github.com/mozsearch/mozsearch/pull/569#issuecomment-1251358638 it sounds like our use of vagrant is actively blocking potential contribution from windows users and I don't think it's really done us any favors on linux either. I'm going to try and do a time-boxed attempt at getting searchfox building/running under docker on linux and, assuming that works, get it running on Windows under a WSL2 Ubuntu VM. If that works I'll try and touch base with people and see if anyone can try it under Docker Desktop / if I should order that and try that myself.

On Ubuntu, after installing the package "docker.io", it should be possible to run:

• ./build-docker.sh to build a "searchfox" image
• ./run-docker.sh to attach the image

Once in the VM, it should be possible to cd /vagrant and then make build-test-repo and then access the searchfox web UI via http://localhost:16995/ like could be done with the vagrant VM mechanism.

:botond just stood up a new VM on PureOS 10 (a Debian derivative) and ran into trouble with vagrant but docker seemed to be smooth sailing (apart from a lingering vagrant SSH tunnel). So I think the right course of action as I finalize the docs and scripts here is to:

• Leave the Vagrantfile intact, but extract all vagrant-related VM guidance into its own markdown file and make sure that the file and the reference to it are like: "do you really not want to use docker on linux or docker under WSL2 on windows? then you can use vagrant but it may not be fun".
• Pitch the (open-source, non-commercial) docker-based solution exclusively, noting that if you have an appropriately licensed docker desktop you can use it somehow, probably.
• try and figure out how to get docker working happily on mac. It sounds like podman might be a more supported option, and that sounds like something some people are already using, so perhaps that might be the way to go. I don't have an M1 macbook though, so I may need help from people to figure this out.

I'm marking this fixed and filed bug 1812838 for follow-up on the docs.