Work on 2014-08-02
Spent 2 hours getting this pull request ready.
kallithea
-
-
Work on 2014-07-12
The unit tests now run inside of containers managed by fig. I wrote two scripts to facilitate the execution:
- integration-configs/fig-config-glue.py: reads environment variables set by fig to create a sqlalchemy URL and update an ini file with it.
- integration-configs/execute_tests.sh: runs the above script, updating test.ini, then sleeps for 10 seconds while the database starts, then runs nosetests
I had been switching between the various databases just by using a different fig configuration file, but that is insufficient. Fig must be invoked with both of the following arguments:
fig -f fig-${DB_TYPE} -p kallithea-${DB_TYPE}If a project name isn’t specified, fig won’t differentiate between the various database containers (all named “db” in the configs).
Of course, different numbers of tests fail in each configuration (including some sqlite tests that don’t fail when I run it directly on my machine without docker in the middle), so there’s still some testing and adjusting to complete.
Another annoyance: when the tests complete, fig shuts down both containers, but fig’s exit code is always zero even if one of the containers exited with a non-zero return code. Going to ask the team if that’s by design or if they’re open to changing it. As is, I’ll need to either parse the nose output or parse the output of
fig psto give an appropriate exit code to the build server. -
Work on 2014-07-11
New info regarding Docker, ENTRYPOINT, and CMD.
I thought I could use ENTRYPOINT to load up environment variables and do some voodoo with the ini file to get the database connection configured correctly:
ENTRYPOINT ["/bin/bash", "--rcfile", "/code/.figrc", "-c"]So then anything I ran would run after the
/code/.figrcloaded. Except that doesn’t happen. Read the CMD docs again, and you’ll see that if the first argument is an executable, it will be executed via the following:/bin/sh -c, so no/code/.figrc./me sighs
/me comes back after 15 minutes
These are not general purpose images. They’re specifically to run test suites. Why do I care about them working for every case? I can just write a wrapper script and call it a day.
-
Work on 2014-07-10
I spent about an hour tonight working on flexible configurations for testing Kallithea against various databases using Fig and Docker
Fig handles some of the dirty work of linking together Docker containers. Linked containers get environment variables set to define endpoints of the other containers. They use Django as an example and things look pretty easy: since the configuration file is written in python, we can just call
os.environ.get('DB_1_PORT_5432_TCP_PORT').No such luck with Pylons and Pyramid, though: there we use an ini file for configuration. I ran into a few bumps, though.
The
paster servecommand provides an avenue for command line configuration:var=valuecan be repeated to pass in configuration options on the command line, and the named vars can be referenced in the ini file with %(var)s. That’s good.Fig doesn’t seem to support environment variables in it’s YAML configuration files, so
paster serve test.ini dbhost=$DB_1_PORT_5432_TCP_ADDRresults in a literal string “DB_1_PORT_5432_TCP_ADDR” in the configuration. That’s bad, but it can be fixed with a wrapper script.Kallithea’s setup-db command doesn’t support the same
var=valuesetting on the command line thatpaster servesupports. That’s bad, but the wrapper script can rewrite the configuration files rather than pass in values via arguments. That’s where I’m leaving off for tonight.One other dangling question: I tried putting my Dockerfile and Fig yaml configurations in a subdirectory to keep the project root uncluttered, but it didn’t look like Docker liked using
..in place of.. I need to confirm that: there’s a chance that something else was out of line that I didn’t notice.EDIT: turns out that relative paths really aren’t allowed. That didn’t take long to find.