Atomspheric CO2 (PPM)



Uptime verified by

21 October 2014

Codeship CI + Symfony 2 + PHPUnit

We've just moved from CircleCI (which was excellent) to Codeship, because we couldn't afford the Github fees any more. It definitely wasn't as easy as CircleCI, and the UI isn't as tidy. But Codeship works pretty well so far. The Setup Commands for a Symfony app go something like this...

phpenv local 5.4
export SYMFONY_ENV=test
unzip -p app/Resources/Tests/ | mysql -u $MYSQL_USER -p$MYSQL_PASSWORD test
echo "xdebug.max_nesting_level = 250" >> $HOME/.phpenv/versions/5.4/etc/php.ini
echo "memory_limit = 512M" >> $HOME/.phpenv/versions/5.4/etc/php.ini
cp app/config/parameters.yml.dist app/config/parameters.yml
sed -i "s/database_user:.*/database_user: $MYSQL_USER/;s/database_password:.*/database_password: $MYSQL_PASSWORD/" app/config/parameters_test.yml

composer install --prefer-source --no-interaction
app/console doctrine:migrations:migrate --env=test --no-interaction


  1. hi
    i have couple of questions:
    – why are you creating database via mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -e "CREATE DATABASE test" when you can use app/console doctrine:database:create ?
    – i dont quite understand the process or manipulating parameters.yml
    first you create parameters.yml by copying parameters.yml.distand than you are trying to replace values on none existing parameters_test.yml. does this even work? my sed complains that parameters_test.yml doesnt exist.
    wouldn’t it be easier to do sed replace directly on parameters.yml.dist and than save it into parameters.yml ? why do you even need parameters_test.yml and where do you load it? (in config_test.yml?)
    – why do you call migration? dont you already have properly setup mysql by doing create database and importing ?


    gondo / 3:26am / 19 December 2014

  2. You are right on the first point. app/console would be easier.

    The reason we go through the parameters.yml stuff is because we keep a parameters_test.yml in version control. We also test locally, so we still use the old parameters_dev.yml/parameters_test.yml setup for development. On the deployment servers, we just use parameters.yml because there is only one environment.

    We should set this up with environment variables for the database values instead of parameter files, but we’d already spent long enough trying to get it working.

    The is just a seed file (actually a clone of the production database). We only update that occasionally with a new snapshot. It’s a bit contorted, but it means our tests catch a lot of problems that only occur once real (messy) data is put into it. Fixtures are tidier, but since they’re created by the programmer I think they’re less useful.

    Ryan / 10:12am / 20 January 2015

Leave a comment


0.638 seconds