blockspacer / hello-cd Goto Github PK

Steps:

1. Install Docker.

2. Run the following commands in order (let each script finish before running the next):

git clone https://github.com/helmesjo/hello-cd.git
cd hello-cd
./docker/start-registry.sh
./gocd/start-server.sh
./gocd/start-agent.sh

Note: It might take a while the first time, since no image-layers are present locally and must be downloaded.

This will:

• Start a registry, where artifacts are stored as docker images.
• Start a GoCD server, which polls the local repo for changes (commits) which kicks off the pipeline.
• Start a GoCD agent with "docker-in-docker", inspired by the official dind image. It connects to the local server and gets delegated the individual tasks defined by the pipeline.

When all is done, you can run docker ps to verify that three containers are up and running (gocd server+agent & docker registry):

Within a minute when the server has spun up, go to localhost and you should see the pipeline:

Each run can be inspected, and stuff like code coverage can be viewed in custom tabs:

• Trivial one-step scripts, scripts/build.sh & scripts/analyze-coverage.sh (minimal, using CMake).
• Requires only a C++ compiler to be present (cross-platform with docker = easy). Coverage-steps ignored if not GCC & Lcov installed.
• No dependancies on anything else = Docker, GoCD or whatever is optional/easily replaceable.
• All output/artifacts is relative to the install path, which can be passed from the command line (artifacts include libs, docs, code-coverage, test results etc, all in one place.).

• Two, again trivial, scripts (docker/build.sh & docker/analyze-coverage.sh) doing nothing more than starting a container, passing the above build/analyze-coverage scripts as argument.
• Dependencies like CMake & C++ compiler is managed in the docker image = very flexible.
• The containers pass artifacts using private registry (docker commit/pull), currently pointing to "localhost:5000" (which is easily configurable if hosting registry remotely). Alternatively gocd publish/fetch artifact tasks can be used, but they are less storage efficient (docker reuses layers).
• "Artifacts" are the whole build for that commit (source + compiled +docs etc.).

• Server & agents running in docker containers.
• Agents using "docker in docker" (through socket-binding, not pure "dind").
• All logic for the building & testing is in the repo, so starting new server instances is trivial.
• Basic, ready to go scripts to fire up server & registry, automatically connecting agents to the server. (this should be replaced by docker-compose, but currently there is some host-setup needed which isn't trivial with docker-compose).
• Pipeline configuration is kept in repository (server is thus minimal, basically contains nothing more than a "load remote config"-config).
• Jobs are minimal, not caring about artifacts etc. (this is managed by the docker build-scripts). Jobs just run "build.sh" & "runtests.sh", keeping the "heavy" logic out of the server.

• Consider moving over to python & behave for end-to-end tests. See this.
• Fix docker-compose for GoCD setup, including registry.
• Add test-result output (tests passed/failed, details of failes etc), perferably in HTML-friendly format.
• Add support for test coverage, result perferably in HTML-friendly format.
• Add support for static analysis, result perferably in HTML-friendly format.
• Host local gitrepo on docker http server (nginx) and reference this from server & agents using the overlay network driver.
• Do above as separate "pipeline steps", so that they can be easily moved around in the pipeline config depending on their importance/time consumption etc.