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
mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -e "CREATE DATABASE test"
unzip -p app/Resources/Tests/test.sql.zip | 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
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 useapp/console doctrine:database:create?– i dont quite understand the process or manipulating parameters.yml
first you create
parameters.ymlby copyingparameters.yml.distand than you are trying to replace values on none existingparameters_test.yml. does this even work? my sed complains thatparameters_test.ymldoesnt exist.wouldn’t it be easier to do sed replace directly on
parameters.yml.distand than save it intoparameters.yml? why do you even needparameters_test.ymland 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
test.sql.zip?thanks
gondo / 3:26am / 19 December 2014
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 test.sql.zip 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