New Docker approach to test the client

[sbaudoin]

Following the pull request to be able to download the Swarm client from a Jenkins server where the Swarm plug-in has been installed, here is an improvement of the way the Swarm plug-in can be tested in Docker. The PR consists in the following:

• Use of a standard (LTS) Jenkins server Docker container with a default security configuration that allows the Swarm client to register (no setup wizard) and a bind volume to ease the installation and configuration operations
• Automatic installation of the Swarm plug-in in the Jenkins server without the need for rebuilding the Jenkins container
• The Swarm client container downloads the client JAR from the Jenkins server: no rebuild required and the new client download feature is tested
• Use of a Makefile to automate the build and run phases with the items previously detailed. Existing targets:
  • build: compile the plugin (mvn clean package)
  • install: install the plugin-in Jenkins
  • run: starts the containers (docker-compose up)
  • stop: stops the containers (docker-compose stop)
  • clean: stop + cleans the Jenkins home directory so that the next installation will proceed again with a clean Jenkins server
  • deepclean: clean+ destroys the containers (docker-compose down)

[oleg-nenashev]

My recommendation would be to actually implement autotests using Docker Fixtures (embedded in JTH) or testcontainers, but it's aa pretty big effort

[oleg-nenashev]

It needs the Jenkins image to be running when you build the image. IMHO it is not required

[sbaudoin]

On the contrary: the purpose of this is to test the ability to download the Swarm client from Jenkins, so a Jenkins server must be up and running with the Swarm plugin (see the other PR I did)

[oleg-nenashev]

@sylv704 After playing with that a bit, I feel that the current Swarm client retrieval is not ideal. I would propose to do one o the following:

• Revert the ADD => RUN change for download of the client
• Modify the code to retrieve Swarm client when starting the container instead of bundling client when building it

The latter option would be preferable IMO.

[sbaudoin]

This is up to you but I would instead do the contrary so that we can test that we can download the Swarm client from the server (see PR #62).

[oleg-nenashev]

So yes, I stick to the "Modify the code to retrieve Swarm client when starting the container instead of bundling client when building it" proposal.

Do you agree @sylv704 ?

[sbaudoin]

Yes, I agree

[basil]

FYI, #81 implements an integration testing suite for this plugin by downloading the Swarm Client from the server (as suggested above) but without using Docker.

[basil]

Closing in favor of #81.