DockerHub publish through CI

[mcserep]

This PR extends the continuous integration workflow to following the successful compiling and testing of CodeCompass, build the Docker images and publish them to DockerHub, to:
https://hub.docker.com/r/modelcpp/codecompass

The following images are built and published:

• modelcpp/codecompass:dev, the development image (ready!)
• modelcpp/codecompass:runtime-sqlite, the runtime image containing CodeCompass binaries built against SQLite (can be done after Docker runtime image #409 merged)
• modelcpp/codecompass:runtime-pgsql, the runtime image containing CodeCompass binaries built against PostrgreSQL (can be done after Docker runtime image #409 merged)
• modelcpp/codecompass:web-sqlite, the webserver executing container image built against SQLite (ready!)
• modelcpp/codecompass:web-pgsql, the webserver executing container image built against PostgreSQL (can be done after Use PostgreSQL in Docker containers #410 merged)

I propose that the default :latest tag should be an alias to :runtime-pgsql.

[whisperity]

What's the separation of these two stages for? Remember #396, I had seen tangible issues with caching between two jobs of the same build... Even if these are the same build chain, the two jobs are entirely separate virtual machines running, and it seemed that -- for the dependencies, as #396 was meant to cache that -- there is some weird nondeterminism...

[mcserep]

The default stages in Travis are: compile, test and deploy. Until now we have not used stages and all jobs were put into the test stage by default.

Stages are sequential, so e.g. the jobs in the deploy stage are only executed when all jobs in the previous test are finished (and passed). That was my aim here: to only build the Docker images and publish them if the previous jobs have succeeded, because otherwise something might be off and we shall not roll out the new Docker images to the public.
This deploy stage in our case is also configured that it is only executed in the original repository (not in the forked ones) and only upon pushes to the master branch (pull requests to the master are also excluded that way).

The compile stage can be omitted and removed, because we do not use it. Initially I have just listed the default stages and it was left there.

[whisperity]

Alright. That distinction is okay with me. I just wanted to get ahead of the possibility of trying to share things between the stages, as I have experienced it not working in the recent past. (We can't really split the "compile" and "test" stages without sharing the build between the two...)

And I agree with running deploy only if we're comfortable with the test stage.

[mcserep]

Yes, Travis has only a limited support to transfer, well, anything between stages. Only solvable with external providers, e.g. with Amazon S3.
https://docs.travis-ci.com/user/build-stages/#data-persistence-between-stages-and-jobs
https://docs.travis-ci.com/user/build-stages/share-files-s3/

Fortunately we do not need this functionality now, the Docker images are built from scratch each time.
(GitLab e.g. performs way better in this aspect, supporting to transfer so called artifacts between jobs and stages.)

[whisperity]

So, should we remove "compile" from the list, and just keep "test"?

[mcserep]

I have removed it now to avoid any possible confusion.

[whisperity]

So runtime is the image that contains both parsing and webserver operations, and web is the one that is only the web server? Or am I missing something?

[mcserep]

So runtime is the image that contains both parsing and webserver operations, and web is the one that is only the web server? Or am I missing something?

Basically yes. To be more precise:

• the runtime image contains the binaries (and their dependencies), and that is all.
• the web image contains the binaries (and only dependencies of the webserver) and it is configured that upon starting a container created from it, it will launch the webserver as a non-root user.

The runtime image will be available after #409 .

[whisperity]

As for the web image, as I mentioned in #398 already, perhaps, as it is once again not in the scope of this patch, but you should add a TODO on having the web image not contain the parser binary's stuff and install. (I think the current build system is not capable of building just the web stuff.)

[mcserep]

PR completed, please review.

[whisperity]

Looks good to me. I assume we'll have to set Travis up with the appropriate creds.

[mcserep]

Looks good to me. I assume we'll have to set Travis up with the appropriate creds.

Already configured in Travis :)