gitlab-ci.yml file.Īnd then whenever the process finishes (on success or failure), it will shutdown and delete the clone.Īt least, that's the theory. Once the clone is complete, it boots the image, and connects via SSH.įrom there, it triggers whatever processes are inside your. The VirtualBox runner goes through a set process whenever a build is triggered. php vendor/bin/codecept run unit Configuration - config.toml Here is the basic one that I am using: # /.gitlab-ci.yml Ultimately, this makes it much easier to set this up.Īt this point I am going to assume you have some setup you are happy with, and that you have both VirtualBox, and the GitLab CI Multi Runner installed.īefore continuing, if you haven't already done so I would advise you give the VirtualBox executor documentation a once over.Īlso, you absolutely must have a. The reason for this is that the GitLab CI Multi Runner regular calls back to my GitLab server, rather than the GitLab server needing a direct line of communication to my runner box. no login to the router to open ports or whatever) - but this all works without any hassle. From my office I don't have any control of the networking equipment (i.e. This probably seems like a "so what?" sort of issue, but what is more interesting is that the machine sits in my office.
#HOW TO USE VIRTUALBOX TO CODE PC#
What is nice about this setup is that I can leave this PC on 24x7x365 and it will take care of my builds whatever time of day. I use a desktop variety of Ubuntu so I can easily interact with VirtualBox, rather than rely on the headless version. The Virtual Machines sit on a dedicated SSD, which makes the cloning process faster.
On this PC I run Ubuntu 14.04 desktop, VirtualBox, a VNC client, and not a lot else. It's nothing particularly fancy - it's my old gaming PC actually. In my real-world setup I have a dedicated PC that I use as my development 'server'. I wouldn't advise this for a real-world setup. To make things easy to record (in other words, for the purposes of this video only) I have installed the GitLab CI Multi Runner directly onto my laptop. Since recording the earlier videos in this series, my GitLab setup has changed slightly: GitLab 8.8.3Īnd the GitLab CI Multi-Runner version info: Version: 1.2.0
I will cover all of the quirks that I have encountered along the way, and my suggested workarounds / fixes where possible. It is a working solution, but there are quirks that you will need to workaround. I also want to state that I am not advocating the VirtualBox runner as the perfect solution. This limited set of functionality is more than enough to achieve the goal of unit and acceptance testing however. Check the Compatibility Chart for reference as to what functionality is / is not available. Both of them offer only a limited set of features when compared to Docker. The VirtualBox runner is based on the Parallels runner. I want to take this opportunity to say a HUGE thank you to everyone involved in getting the VirtualBox executor into GitLab. Honestly, GitLab and the community surrounding it - heck, Open Source in general - never ceases to amaze me. Thankfully - I have found a solution: VirtualBox Executor gitlab-ci.yml file examples I have been able to find and examine had me convinced that without fully investing in Docker, I would not be able to achieve what I dearly wanted to achieve - running my browser-based (selenium or phantomjs) acceptance tests during a GitLab CI build. There are many reasons for this, but the end result has been that testing via GitLab CI hit a roadblock when it came to acceptance testing. But I also think it has a steep learning curve, and in my personal circumstances, I have not yet had the spare time to invest in migrating my working Ansible with VirtualBox setup over to a Dockerised equivalent. Now, the vast majority of documentation around GitLab CI / the GitLab CI Multi-Runner talks about Docker.ĭon't get me wrong - I think Docker is an incredible tool. Well, repeat after me in your very best Hubert Farnsworth impression:īecause that's exactly what we are going to set up in this very video. Clone your VirtualBox / VMWare VM, and then boot it.GitLab CI could talk back to a machine of your choice.
Wouldn't it be great if you could get your GitLab CI builds to run against the exact same Virtual Machine you use during development? However, setting it up can be costly in terms of time, or money, or both. Continuous Integration is one of the most beneficial things to add to any serious project.
0 kommentar(er)
