feature/16-build-and-upload-docker-images-from-travis

[shanmukhananda]

…p.sh changes.

[shanmukhananda]

appveyor builds are failing because appveyor.yml is not present in this branch. This is part of PR13

[shanmukhananda]

DOCKER_USER and DOCKER_PASS are env vars added to Travis Settings

[paul-michalik]

Have you looked at the automated builds chapter on Docker Hub? Wouldn't it be better to set up something more robust with that? https://docs.docker.com/docker-hub/builds/#prerequisites

[shanmukhananda]

Yes I have tried docker hub's automated build, but there are issues with that.

1. You need to have whole setup instructions written inside Dockerfile.
2. Docker build context cannot be changed, mean Dockerfile should be at root folder
3. Dockerhub's build will never copy dependent files like scripts/bootstrap.sh.
4. They just copy Dockerfile and Readme.md in the root folder of github's project, other files like bootstrap.sh are not accessible
5. Even if we solve above issues, docker automated build creates image on every commit if we link it to a github's repo

We need to upload docker images only if dockerfile or bootstrap.sh is changed.

[paul-michalik]

I got the intention but is this really necessary? Can't we make this a warning or maybe an error - if inconsistent bail out and make the build fail... I am a bit skeptical about the possible side effects...

[shanmukhananda]

If build fails it wont help the user much. User has to contact me and I need to build, test and upload new docker image to my account, which is cumbersome and might open window for errors in my side :-)

Almost every CI pipeline (travis, bitbucket pipeline, shippable, circle-ci, gitlab-ci etc) added support for automated docker build and upload. Many (like atlassin) encourage to use automatic build and upload of docker images. At-least the process wise I think it is correct to automate docker image deployment. We can always improve the conditions when the docker image is uploaded, what meta info is added, where it is upload etc in future.

Since the feature for continuous delivery of docker images in build servers is new feature, we dont see much github projects using it.

Useful links:
https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/docker.md
http://docs.shippable.com/ci/push-docker-hub/
https://blog.bitbucket.org/2017/04/18/bitbucket-pipelines-supports-building-docker-images-and-service-containers/
https://circleci.com/docs/1.0/docker/

[paul-michalik]

Which OS version is travis using? Can't we require Ubuntu 17 and use with the non-dockerized setup?

[shanmukhananda]

Travis uses Ubuntu 14, it provides us with old tools like OpenCV2.4, gcc 4.8, cmake 3.5. Not much suitable for us. Ofcourse we can make it work but it requires few changes in cmake and may be in code if we are using latest c++. But I recommend current containerized build approach.

[paul-michalik]

What range of differences are considered here? How do we now that the user didn't create a new image? Or is this intended for travis usage only?

[paul-michalik]

We are currently looking at changes in HEAD^ which touched Dockerfile or the script. Is this sufficient? What I am missing is a last known state when the image was created. So I'd expect a range of commits starting at the known point where current image was created. This requires that this is somehow encoded in the image name or image metadata. Maybe "docker inspect" can help? Or tagging the image with current commit hash?

[shanmukhananda]

git whatchanged is used for travis purpose only. to check if a file is changed in the current commit.

User cannot upload a new image, Only I can upload a new image. travis pushes and pulls from my docker repository
Even if I upload some wrong image to docker hub. Travis uploads a new image if dockerfile/bootstrap.sh commit is on master.

Last state can be tracked, because we adding travis build number to docker image tag.
This has been explained in detail in below comment
#16 (comment)