A few days ago I received an invitation for Bitbucket’s new pipeline feature (right now in beta). For those, who haven’t heard of it yet, it’s a CI add-on within Bitbucket to seamlessly test your apps without the need of external services. For quite some time I use BB as Git host for my private repositories, so I was very curious to try it out. But wait? Isn’t this article about Codeship? Fair point. It is. I wasn’t able to run tests with BB pipelines because I had trouble with the SSH setup, so I decided to give Codeship a try.

Codeship’s default settings

One disadvantage of CS is their lack of documentation. Well, in most cases CS simply works out of the box. But sometimes it’s pretty annoying to search through external forum posts. However, before we start to set up our testing environment, here are some important things to know about CS:

  • There’s no need to install PHP, Composer or MySQL before you can run your tests—CS already provides everything set up in their VMs.
  • Also, CS creates you a MySQL database named test and a user named root with the password test.

Environment Variables

When you’ve worked with Laravel before, you should be familiar with environment variables. Set them up in the project settings, so there’s no need to patch them into the deploy script.

Environment Overview.

Test configuration

Once all variables are set, we need to configure the tests. Here’s my basic setup:

# Set PHP version
phpenv local 7.0

# Remove XDebug
rm -f /home/rof/.phpenv/versions/$(phpenv version-name)/etc/conf.d/xdebug.ini

# Increase memory
sed -i'' 's/^memory_limit=.*/memory_limit = 512m/g' ${HOME}/.phpenv/versions/$(phpenv version-name)/etc/php.ini

# Install dependencies through Composer
composer install --prefer-source --no-interaction

# Seed database
php artisan migrate:refresh --seed

# Start the PHP server
php artisan serve >/dev/null 2>&1 &

When I first tried out Codeship about a year ago, my tests often failed because they were using too much RAM. By default, Codeship only offers you 256 MB and already has XDebug pre-installed. If you don’t require XDebug, I’d recommend you to uninstall it and increase the shared RAM to avoid memory issues.


Because I’m currently on the free plan, I only use one pipeline. By running ./vendor/bin/phpunit all tests specified in the phpunit.xml are being executed.

Test Details.


Most of my recent projects are being hosted on AWS and deployed via Laravel Forge. For some branches I want my code to get pushed to the server right after all tests are ok. Setting this up is very easy: Open your target site in Forge’s site details and grab the trigger URL.

Site Details.

Then tell CS to use a custom script as deployment pipeline and do a simple WGET:


Test Overview.

That’s it. Happy TDD!

Marco Raddatz

Marco Raddatz


Marco Raddatz Private blog of Marco Raddatz from Hamburg, Germany. Back to Overview