Continuously test vagrant ubuntu-setup

[domdom82]

In the past couple of days some installation attempts using vagrant have surfaced bugs:

#309
#305
#295
#294
#292

I propose (and volunteer) to write a test that does a vagrant install from scratch and checks if all tools (docker, gradle, ansible, etc.) work correctly.

This basically means

vagrant up
source all.sh

and check for errors.

Travis seems not not catch those issues.

[domdom82]

Did run some tests on travis, findings so far:

• in theory, you can install virtualbox and vagrant on the travis container.
• you need to put these in travis.yml:

  - sudo apt-get install -y linux-headers-$(uname -r)
  - sudo apt-get install dkms -y
  - wget http://download.virtualbox.org/virtualbox/5.0.20/virtualbox-5.0_5.0.20-106931~Ubuntu~trusty_amd64.deb
  - sudo dpkg -i virtualbox-5.0_5.0.20-106931~Ubuntu~trusty_amd64.deb
  - sudo wget -nv https://releases.hashicorp.com/vagrant/1.8.1/vagrant_1.8.1_x86_64.deb
  - sudo dpkg -i vagrant_1.8.1_x86_64.deb

• problem A: travis timeout is going to bite us. the vagrant download takes about 25 mins. timeout is 50 mins. without forking this into a separate travis build, it is not going to work.
• problem B: our vagrant box requires a GUI (reasons beyond me) which we don't have on a build machine.
• problem C: we probably don't want to test the vagrant image every time we do a commit. the travis build should be as quick as possible to allow fast development. I don't know of any possibility to schedule travis builds on a per-day basis.

alternative solution: move this issue to our own build env and do it with jenkins.

[domdom82]

@jeremiaswerner @markusthoemmes @sjfink @rabbah your thoughts?

[rabbah]

problem B: our vagrant box requires a GUI (reasons beyond me) which we don't have on a build machine.

really? the gui is optional and not installed by default.

i might be confusing this with something else - can you clarify.

[csantanapr]

about problem B: No GUI is required, I'm using vagrant with no GUI.

I think using our jenkins will be the solution to test vagrant setup based on problem A and C

[sjfink]

brainstorm: we have in my lab Mac Minis we can use as we like.

How about a "normal" jenkins build that runs the vagrant build on a MacOS slave?

[domdom82]

@csantanapr did you patch the Vagrantfile?

   vb.gui = true

seems pretty hard-coded to me. Does it work ootb if you do not have a GUI? Did you set it to false on your env?

[rabbah]

Ah - I am sure we can make this optional.
I was thinking of the ubuntu-desktop.sh - so for that to work, gui must be true, but we don't need to turn on the gui if the common case is not to use a deskop in the vagrant machine.

[domdom82]

I would agree. The only benefit you get is when used in conjunction with ubuntu-desktop.

[csantanapr]

@domdom82 I would leave vb.gui = true for users not have to change it if they want GUI, this way users just need to run the ubuntu-desktop script

I would assume that having vb.gui in jenkins slave would just be ignore and work, if you tested and it doesn't work then I think we just need to flip it to false dynamically when running the build in jenkins

[rabbah]

It can be factored so that it can be overridden is the point - with a default of true to preserve current behavior. This is how shared works.

[domdom82]

we could make

GUI = ENV['VAGRANT_GUI'] || true 

[domdom82]

added option to disable GUI using

VB_GUI=false vagrant up

should we document this in readme? where?

[csantanapr]

doc in the readme as a note, for headless systems that don't support GUI

[rabbah]

Closing as wont fix. See #4779.