Running functional tests against an Omnibus instance
We currently don't support Omnibus installations at all, but it's technically not far from working and there's immediate value to provide the base fixture class for them.
The GitLab monolithic Docker images is nothing but an Omnibus instance with a fixed Linux distribution providing the base user land (currently Ubuntu 16.04) and a general starter script. Heptapod Docker images add more software and configuration on top of that, but we are close to the point where there's nothing to add.
Once we have an OmnibusHeptapod
base fixture class, we can launch the tests from the inside of a container, and we can also do it for the current stable series (Heptapod 0.16). In turn, this means that we can have a CI job that launches the tests that are skipped with the --heptapod-remote
option we use on CI, without resorting to Docker in Docker.
No more manual testing would be required for intermediate Docker images and releases. As an extra bonus, once the Docker image is the one provided by Omnibus Heptapod, we can trigger everything from the Omnibus (or even Rails) tag push, saving many hours of work. It would be very nice to produce Heptapod 0.17.0rc1 this way.
Mostly what has to be done is a middle ground between the current SourceHeptapod
and DockerHeptapod
classes:
- using
gitlab-ctl
andgitlab-rake
as inDockerHeptapod
- direct file system access and subprocess spawning as in
SourceHeptapod
- HTTP and SSH management as in
SourceHeptapod
- file system paths as in
DockerHeptapod
(hence hardcoded to the default Omnibus ones). Later on we could also read them from configuration.