It is simpler to expect that rvm setup is done outside of this build.
The buildacloud.org jenkins has rvm installed/enabled by default so
does not invoke rvm.
Running --export creates the .ovf and the .vmdk files referenced
from that .ovf in one go. Guessing/predicting the names of the .vmdk
files is not fool-proof.
The backticks in the Vagrantfile template were getting evaluated by bash.
This caused some harmless but confusing error messages to appear on running
the build. Easy fix is to remove them.
* bundle install needs to run before running the vbox cleaning scripts,
so move prepare step before clean step
* feature branches have / in their name which is a bad character to
put into filenames
Veewee supports exporting vagrant boxes out of virtualbox, out of the box.
However, it assumes that it can export a disk if the shutdown of the vm that
is using that disk has succeeded. This assumption is not strictly always true
(see previous commit). So, we replicate the bit of logic in veewee for making
vagrant boxes.
This has the added side benefit of creating an .ovf export only once, rather
than once for vmware and then again for vagrant.
Having experimented with many edge cases of running multiple build.sh
commands in parallel / against busy virtualbox setups, the only really
reliable way to produce consistent images is to not do these commands
in parallel and to not do them while the machine is doing many other
things.
If virtualbox or the machine that hosts it is very busy, and/or it has
a lot of disks it knows/knew about, and/or its tuesday, behavior may
be a bit different.
Realizing this reality, this commit adds some scripts that try really
hard to set virtualbox back to known/healthy state before building.
Create a new minimal 'debianbase' definition which is a veewee template
that's a lot like the systemvmtemplate, but does not have any
systemvm-ness in it. Use it to create a new test.sh which tests a few
common invocations of build.sh work as desired.
This is mainly useful for debugging whether the appliance build process
is working / consistent; in order to test a systemvm itself it should
really first be merged with systemvm.iso.
The current build downloads its script from master by fetching a cloudstack
tarball. Besides being an unneeded load on the apache git server, this is a
problem when working on a branch and wanting to inject a different set of
scripts. It also makes it pretty likely that the injected copy of the script
will not match what a production release wants, so there is very little
chance of not needing to overwrite the scripts.
Ideally we would just rsync over some files. However, veewee does not provide
an option to do that. In order to keep a 'cleanly veewee-only' build possible,
and work with any recent veewee version, in this change we restor to using
shar (http://en.wikipedia.org/wiki/Shar) to produce an archive which can
execute as a script, which we feed to veewee to execute.
When working on the systemvm in isolation, or using vagrant or similar tools,
it can be useful to inject a custom SSH key before merging a management server
systemvm.iso into it. This option allows that. It should _not_ have effect
on management-server-managed vms which always get their SSH keys injected.
In particular, this refactoring allows the use of 'set -e' to exit early on
error. Previously the script would continue for a while when encountering a
problem, stuttering sometimes to (almost) completion, producing partial or
no results.
Added a bash on EXIT trap which runs add_on_exit cleanup code in the reverse
order it was specified. Resource cleanup is now co-located with resource
definition.
Added color-coded logging.
Made most of the hypervisor-specific exports optional. This script now
works on Mac OS X.
Added a bunch of possible arguments / environment variables, see the new usage
function for details (or run ./build.sh help).
Creates a new template with a unique name on every invocation, resulting in a
new virtualbox instance with a unique name. This makes it possible to build
multiple boxes at the same time, in parallel (including for example on a
multiuser box), and reduces the chance of failed build results conflicting
with each other.
Inject the version given on the command line (if any) into the created image.
Taken from Junio C Hamano's blog [1], git's maintainer, he must not be wrong :)
[1] http://git-blame.blogspot.ch/2013/06/checking-current-branch-programatically.html
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit e16414e56d8f398f8ddbbde89d3ee833582b8bb2)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
When both systemvmtemplate64 and systemvmtemplate are present the grep
match fails and returns (non-deterministically) the 64bit appliance
instead of the 32bit one. Fix this by matching the path separater as
well.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
The fix makes systemvmtemplate as the default veewee vbox appliance if not
other appliance is provided to be built
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
