[Proposal] Continuous Deployment process of the image with Travis

[dduportal]

Hello, @mojavelinux @gscheibel @jirutka and all the contributors!

I am opening this issue to discuss (before jumping in any implementation) about the CD process for this image.

Challenge Statement

My goal is to propose an implementation with TravisCI, that will take care of the building, testing and deploying the image in the most automated way possible.

• Currently, as stated by @jirutka in Asciidoctor upgraded to 1.5.6.1 #47 (Asciidoctor upgraded to 1.5.6.1 #47 (comment)), Travis is not tracking nor building the repository: https://travis-ci.org/asciidoctor/docker-asciidoctor.
• We still want the image to be available on the DockerHub: https://hub.docker.com/r/asciidoctor/docker-asciidoctor/
• Since Migrate to an Alpine-based image & introduce a test suite #39, we want the test harness to be run for each Travis build, to allow any new contributor to feeling safe about their proposal, ensuring non-regression in the future.
  • The property of "failing test == no delivery" is important on the master branch.

Current Status

My proposal is focused on the "Automated Builds" of the DockerHub: https://docs.docker.com/docker-hub/github/.

Currently, we use this for this repository: DockerHub is watching for any change on the repository and will build itself the image (and deploy it in the registry).
=> The main issue is that the test harness is not run by the DockerHub.

Proposals for Solving Challenge

• If we move the build on TravisCI (watching events on the repository), we could gain the value of running the test harness on each commit/Pull Request, with direct Feedback to GitHub.

• The Docker Image delivery need to be discussed. Once the repository has been built and tested successfully in Travis, should we:

  • Use docker push to deliver it to the DockerHub
    • Pro: The image on the DockerHub is exactly the same (binary speaking) as the one tested
    • Con: The "trust" with the Docker platform is broken since they cannot be sure "where" the binary come from.
  • Or send a webhook to the DockerHub to kick an "Automated Build"
    • Pro: We have a chance that the tested image differs from the one built by the DockerHub
    • Con: DockerHub users can go back on which Dockerfile / git commit has been used for each tag

=> I propose the webhook solution (where we disable the DockerHub watching). Even if we have a risk to differs, the fact we are using tagged version for a lot of the components + using Alpine Linux make it "leaner".
Since I already did it for other personal projects, I can apply this on my fork and let you check this, before applying it to this repository.

What are your advises on this?

[dduportal]

Ping @mojavelinux @mgreau what do you think on this topic?

[mgreau]

Great proposal @dduportal

Con: The "trust" with the Docker platform is broken since they cannot be sure "where" the binary come from.

What does it mean exactly? As we have to be logged to push the image, I'm not sure to see the difference (I use this process for my personal docker images)

[dduportal]

Hello @mgreau . I am working on this topic right now, and I just was your message here.
Thank you for the feedback (and your patience since I just saw your message...).

So in the proposed process, the idea is to have a "deploy" phase on the CI build, that will trigger a build in DockerHub:

• The DockerHub configuration consist in disabling the GitHub watching, and enabling build trigger.
  A token will be generated, which can be stored as "secret" in any decent CI configuration (it is the case with Travis):

• Then, a CURL with right parameters in the payload can be used to specify if we want to scan all "configured builds" on the DockerHub, or just a tag or branch specifically. It looks like this on my Makefile:

deploy:
	curl -H "Content-Type: application/json" \
		--data '{"source_type": "Branch", "source_name": "$(CURRENT_GIT_BRANCH)"}' \
		-X POST https://registry.hub.docker.com/u/dduportal/docker-asciidoctor/trigger/$(DOCKER_HUB_TOKEN)/

The idea is to avoid pushing image on the DockerHub it it is not tested AND providing the trust of the users on the DockerHub since they can know which Dockerfile has been used for each tag.
The tradeoff is that the rule of "binary reuse across the build pipeline" is not followed: there can be a diff between the image built by Travis, and the image built by the DockerHub. I feel this is acceptable since we aim for build reproductibility.

Let me open a Pull Request on this subject so you'll have material to review.

[dduportal]

Closed by #61 a while ago.