Episode 6

TYPO3 core testing infrastructure – Part 2

The new Core CI setup

System overview

We started in part 1 with some reasoning on why we’ve put our hands on the test infrastructure again. This part starts with technical details.
Let’s have a look which systems interact with each other.

Rough test job overview

Each change pushed to the review system runs through an excessive list of tests. At the time of this writing, we’re dealing with roughly these scenarios:

Some of these test suites (especially functional and acceptance) take hours if executed in one go. Since we want to have a full-suite result after a couple of minutes, we split those tests into multiple jobs. This currently turns into roughly sixty jobs to be executed for each change. This number is different depending on core branch, and changes frequently, for instance when a TYPO3 version starts to support additional PHP versions. The nightlies extend this even further by testing a series of more uncommon permutations.
A single job typically occupies at least one CPU - we really need some hardware to deal with this if we always want a reasonable quick testing result.


The testing infrastructure boils down to these systems:


This view is biased: Christian Kuhn as the author of this blog series has been using hetzner.de services for about fifteen years and always received this provider as reliable. There are alternatives.

Hetzner cloud

hetzner.de is known for their root servers that give a good price / performance ratio. They are a suitable opportunity as a hardware provider when you know what you are doing on a server level. 

With the ‘go-cloud’ hype-train, hetzner added an own solution a while ago: The hetzner cloud provides a web interface to click differently sized server instances on the fly and pay for them minute-based. They also provide a programming API to do that code-based. This is similar to what AWS, google cloud and others offer on this level.

In the end, hetzner cloud is a great solution to host stuff like those auto-scaling test runners or small instances like the gerrit-adapter - especially when further dedicated test hardware is also hetzner based.

DevOps tooling

The GitLab instance is maintained by the server team. We’ll not have a closer look at its setup and maintenance. The runner setup however is managed by the core team. Let’s have a look which DevOps tools we’re using to deploy the infrastructure:


This part gave a rough overview of involved systems, their management and used tools.
Special thanks goes to Stefan Wienert for this blog post, and to TYPO3 community member Marc Willmann for this blog post.
Next part will dive deeper into the rabbit hole by looking at the docker setup used for testing.

More Articles by Christian “Lolli” Kuhn