Bailador 0.0.10 has been released yesterday.

Basically it was a release that not really contained any shiny new features nor bug fixes. It was a release that addressed things we did wrong in our test cases. Tests especially matter whenever you want to install a module, so you could say that this version was just released to allow an installation of Bailador without running into errors.

So what happened?

Right after the previous release Gabor came along with a bug report saying Bailador raises an error during installation. The error itself happened in the test case 20-cli.t which can be considered as our first try to do some integration testing. Personally I think this is one of the test cases that didn't see much love, is not a pleasure to read, maybe because it is quite full of code and diags which are commented out. So let me point out a few things it does:

• Invocation of bin/bailador without any parameters to check for its usage.
• Invocation of bin/baildor new --name=App-Name that should create your app with some skeleton files.
• Invocation of prove6 -l App-Name/t.
• Invocation of the newly created app and http'ing into it.

So what is special about this?

Well, with the code itself? Nothing! Maybe it is also worth pointing out the fact that Bailador's travis-ci was green, so our test worked for us. The differences of the premises for the failing test comparing the bug report to our test scenario was the command zef install Bailador. Whereas our test case at travis did a zef install --deps-only .. After a while I realized that zef itself is quite smart because if you install some::module with zef install some::module it is most likely that some::module has some::dependencies and even::more::dependencies. What if some::module can not be installed? Right. The dependencies don't get installed on your system. But this means that when zef runs the test for some::module they need to have access to the dependencies. Zef manages this through setting the PERL6LIB environment variable. So that was missing in your test code! After changing this behaviour most of the tests passed except for one, because I was not able to get the prove6 test case up and running.

docker on travis-ci

In the meantime pharv joined our slack channel and sent a PR to use docker in our travis-ci setup. This reduced the test time from 27min to 7min. Yay! The image that we use is rakudo-star and the commands we're running in the .travis.yml are now:

docker run -d -e 'AUTHOR_TESTING=1' --volume=$(pwd):/srv --name bailador-test bailador/bailador /bin/sleep infinity
docker exec -it bailador-test zef --verbose install .
docker exec -it bailador-test prove6 -v xt
docker stop bailador-test
docker rm bailador-test

Maybe it is a bit unconventional not to include the source within the Dockerfile ( COPY . /srv ). Instead I am using a volume when I start the container. The benefit is that I use basically the same commands to test Bailador on my local box:

$ cat .zshrc

...
function bailador-test() {
        cd /home/martin/.workspace/p6/Bailador
        docker rm bailador-test-container
        docker rmi bailador-test
        docker build -t bailador-test .
        docker run -d -e 'AUTHOR_TESTING=1' --volume=$(pwd):/srv --name bailador-test-container bailador-test /bin/sleep infinity
        docker exec -it bailador-test-container zef --verbose install .
        docker exec -it bailador-test-container prove6 -v xt
        docker stop bailador-test-container
}

and whenever something is failing I still have the same container up and running. I can fix the files with my editor on my local box and the changes are reflected in the docker container as well and I can redo whatever step was failing.