Broken backwards compatibility

[christopher-hopper]

Problem/Motivation

In the interests of stability we pegged our Vagrant beet/box version constraints to stick with our last known working version (>= 0.2.7, <=0.4.4) for our projects. The reason for this is that:

1. we use our custom ansible roles as pre/post tasks
2. previously, beet/box base box updates had broken project VMs unexpectedly
3. ensuring stability of environments for Support and Project teams is a key consideration

Unfortunately now all our builds are broken because a file was removed from the master branch.

Expected behaviour

After pegging the Vagrant beet/box version at less than 0.5.0 you should be able to start a VM.

Actual behaviour

The following error is received after running vagrant up.

There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/chopper/Projects/foobar/baz/Vagrantfile
Line number: 17
Message: RuntimeError: Can't access https://raw.githubusercontent.com/beetboxvm/beetbox/master/.beetbox/Vagrantfile.

Steps to reproduce

1. Create a project with a beet/box Vagrantfile from tagged version 0.4.4
2. Add a .beetbox/config.yml as per the documentation

3. Insert the following two lines into the .beetbox/config.yml as per the documentation

   # Stick with known working beet/box versions.
   vagrant_box_version: '>= 0.2.7, <= 0.4.4'

4. Start-up the machine with vagrant up

Proposed changes

Do not remove files required by older versions from the Internet, or if you do, provide redirection to a new Internet location so older versions still work.

[christopher-hopper]

Looking at the path being downloaded, I'm thinking perhaps it should have pointed to the tagged version path, rather than the master branch path. It's too late now to go back and fix that in all previously tagged versions, but this should be a consideration for future versions.

[thom8]

@christopher-hopper ironically this is the exact problem we're trying to fix by only supporting composer installations which pin to specific versions.

Future, versions will always use the Vagrantfile of that specific version :)

You can either switch to composer or update the remote Vagrantfile reference :

eg. https://raw.githubusercontent.com/beetboxvm/beetbox/master/.beetbox/Vagrantfile >> https://raw.githubusercontent.com/beetboxvm/beetbox/0.4.4/.beetbox/Vagrantfile

With composer this is no longer an issue for future versions 😄

[thom8]

composer require --dev beet/box:~0.4.4 would be the recommended way to resolve this issue.

[thom8]

With composer you also don't need to specify

# Stick with known working beet/box versions.
vagrant_box_version: '>= 0.2.7, <= 0.4.4'

https://github.com/beetboxvm/beetbox/blob/0.4.4/.beetbox/Vagrantfile#L19

[christopher-hopper]

We can't switch to the composer installer method as it doesn't fit well with our CI and CD platform.

I'll pass this onto the team as an interim fix. We'll need to consider our options for future usage patterns. There's been some discussion internally about moving to local docker builds, and/or our own packer built box for Vagrant, so this may be the catalyst for a change.

[thom8]

Not sure why you'd need Vagrant for CI/CD.

Anyway, I'm also looking into the feasibility of adding docker support to this project to but still waiting on a few performance improvements to become more stable.

[thom8]

You also have the option of using composer to just manage the install / update of packages and commit everything to the repo -- https://www.codeenigma.com/build/blog/do-you-really-need-composer-production