1110345 - Add recommended VM setup steps for Windows users to "Creating an environment" docs

Status: RESOLVED INCOMPLETE

(Developer Services :: General, task, P2)

Description

[Ed Morley [:emorley]]

Ok, so the docs at http://mozilla-version-control-tools.readthedocs.org/en/latest/testing.html do say that Linux or OS X is required, so to use a VM if not on those platforms - but for reference I'll include my experimentation with trying via MSYS as well as the later VM frustrations.

Issues using MSYS2 on Windows:

1) "./create-test-environment: line 9: venv/bin/activate: No such file or directory"

-> Bug 1110159

I made the necessary local change to create-test-environment and tried again.

2) "error: Unable to find vcvarsall.bat"

-> Bug 1110186

I appended the necessary lines to venv/Lib/distutils/distutils.cfg and tried again.

3) Hit: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

-> Bug 1110199, likely my fault.

Ok, so at this point I gave up with trying to defy the docs - and not wanting to mess with some of my other VMs, thought I'd just |vagrant init| a basic box (hashicorp/precise32 - is the base library box used commonly throughout the Vagrant docs and in a few of the Vagrant projects I use) and try from there - added bonus I can share the srcdir and not have to reclone everything in a new VM.

4) Hit "oserror: [errno 71] protocol error" when create-test-environment tries to make the venv

-> ah yeah I forget since it's been a while since I've used a project with the venv in the shared directory, but on Windows virtualenv creation errors out when run from a directory being shared, due to the lack of symlink support on Windows - so you have to create it with --always-copy instead.

Let's try create-test-environment again.

5) Ok so turns out the hashicorp/precise32 base image is a bit too basic. After numerous failed pip installs (with no caching, so it downloads each time - why didn't I set –download-cache from the outset, hindsight... sigh) it turns out I need to install python-dev, make (I mean really Ubuntu?!), libxml2-dev and libxslt-dev first.

So at this point after getting 95% of the way there to getting an environment set up in the Vagrant VM (and waiting for what seems like an age for numerous Hg versions to compile), it seems like I'm onto a winner.
Or not. Since it turns out Docker segfaults on this kernel version & has a whole number of workarounds that are necessary for Ubuntu 12 LTS. Sigh.

Right, let's blow this vagrant project away and try the newer ubuntu/trusty64 library base image (at this point I'm wishing I had remembered the Ubuntu naming scheme better from the outset, and so had known that precise32 was 12LTS and so ancient, bah).

After repeating the above with the new VM...

$./create-test-environment

6) Installing Pillow fails with:
   running build_ext
   error: [Errno 26] Text file busy: 'build/temp.linux-x86_64-2.7/multiarch'

...which is apparently due to it being done in a shared Vagrant directory.

Ok so time to locally modify create-test-environment some more, so the venv is outside the srcdir.

7) building 'lxml.etree' extension
   ...
   x86_64-linux-gnu-gcc: internal compiler error: Killed (program cc1)

-> Turns out that Virtualbox/Vagrant uses a default of 512MB RAM and that isn't sufficient. But thanks for the helpful failure mode gcc, sigh. 

Ok, so I bumped the RAM to 1024MB.

8) building 'lxml.etree' extension
   ...
   /usr/bin/ld: cannot find -lz
   collect2: error: ld returned 1 exit status

-> Turns out that means I'm missing zlib1g-dev too.

Yey finally appear to have a working test environment...!

(.venv)vagrant@vagrant-ubuntu-trusty-64:/vagrant$ ./run-mercurial-tests.py -j2 hgext/reviewboard/tests/*
ssssssssssssssssssss.
Skipped test-bugzilla-review-interaction.t: irrelevant
Skipped test-auth.t: irrelevant
Skipped test-commits-deleted-obsolescence.t: irrelevant
Skipped test-review-request-closed-discarded.t: irrelevant
Skipped test-push.t: irrelevant
Skipped test-commits-deleted-no-obsolescence.t: irrelevant
Skipped test-review-request-delete-draft.t: irrelevant
Skipped test-review-request-closed-submitted.t: irrelevant
Skipped test-bugzilla-review-flag-cleared.t: irrelevant
Skipped test-folding-obsolescence.t: irrelevant
Skipped test-commits-added.t: irrelevant
Skipped test-multiple-precursors.t: irrelevant
Skipped test-user-apis.t: irrelevant
Skipped test-obsolescence.t: irrelevant
Skipped test-bugzilla.t: irrelevant
Skipped test-unicode.t: irrelevant
Skipped test-multiple-parents.t: irrelevant
Skipped test-fetchreviews.t: irrelevant
Skipped test-store.t: irrelevant
Skipped test-push-invalid-bug.t: irrelevant
# Ran 1 tests, 20 skipped, 0 warned, 0 failed.

...wait, why were they all skipped? /me bangs head against wall.

All I wanted to do was to fix the test failures in bug 1098093 so I could land it and return to working on Treeherder, and I've now spent a not insignificant amount of time playing around trying to get this to work :-(

Anyway sorry for the mammoth comment 0, and yes I should have not tried to see if it would work in MSYS on Windows, and yes I should have probably not tried using Ubuntu precise. 

That said, it's pretty frustrating experience for Windows users at the moment with the current scripts/docs. Saying "we don't support Windows natively" is fine, but if docs could be improved or a Vagrant/boot2docker compatible docker image checked in, that would help greatly - since I imagine there are perhaps non-employee contributors who might be willing to help with mozreview, but give up and move onto another project - since there are many that work perfectly fine on Windows (or have a working-out-of-the-box Vagrant image).

Thanks :-)

Comment 1

[Ed Morley [:emorley]]

Since I filed this bug, https://hg.mozilla.org/hgcustom/version-control-tools/rev/e08ca2467e6d updated the docs, and they now say:
"If you are on Windows or want to create a fully-isolated environment, the Vagrant configuration used by Jenkins provides a fully capable environment.":
http://mozilla-version-control-tools.readthedocs.org/en/latest/devguide/environment.html

However the jenkins page is pretty vague on how to use the VM as a development environment, vs hooking it up to Jenkins. My gut instinct was that run-main.py was going to do more than I wanted. Also, what are the paths to the source repo? How can I get it to mirror my source repo outside the VM? etc. All things I can figure out, but would be great if they were documented in a list of bullets for new contributors, so save everyone working out the same steps.

I'll update the bug once the Vagrant provision finishes - 20 mins in and has been stuck on this for at least 10 minutes:
==> default: Setting up lxc-docker-1.5.0 (1.5.0) ...

Comment 2

[Ed Morley [:emorley]]

Draft steps for docs:

1) Install Vagrant / Virtualbox
2) Clone version-control-tools repo
3) $ cd testings/jenkins
4) $ vagrant up
5) If it appears to hang, try again using |vagrant destroy && vagrant up| (bug 1143262)
6) $ vagrant reload (since the VM moans about needing a system restart due to the updates)
7) $ vagrant ssh
8) $ cd /version-control-tools
9) $ ./create-test-environment

Though that gives:

New python executable in venv/bin/python
Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 3, in <module>
    virtualenv.main()
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 825, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 985, in create_environment
    site_packages=site_packages, clear=clear, symlink=symlink))
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 1405, in install_python
    os.symlink(py_executable_base, full_pth)
OSError: [Errno 71] Protocol error

-> which is #6 from comment 0. tl;dr the virtualenv needs to be outside the srcdir, since the srcdir is a virtualbox shared folder.

Comment 3

[Ed Morley [:emorley]]

I edited create-test-environment to put the venv in ~/venv and re-ran, but got:

pulse> Step 7 : CMD /usr/sbin/rabbitmq-server
pulse>  ---> Running in d05ab892ff59
pulse>  ---> 7864f131bcf9
pulse> Removing intermediate container d05ab892ff59
pulse> Successfully built 7864f131bcf9
Error running mach:

    ['build-mozreview']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

OSError: [Errno 2] No such file or directory

  File "/version-control-tools/testing/vcttesting/docker_mach_commands.py", line 52, in build_mozreview
    self.d.build_mozreview(verbose=True)
  File "/version-control-tools/testing/vcttesting/docker.py", line 358, in build_mozreview
    name, image = f.result()
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 397, in result
    return self.__get_result()
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 356, in __get_result
    raise self._exception