Before we dive into the configuration of the pipeline, let us quickly look at how the build process is organized. First thing to note is that our solution is now technology rich: Fabric, Composer, go, node.js. These technologies have quite a few dependencies that needs to be in place for the build to work; Think about the pre-requisites for Fabric and Composer, go and its libraries, NVM, NPM, Node and all the packages deployed.
To get a consistent build output between the local and remote environment we need to have a way to reduce and contain the dependencies.
This is where the approach of using Docker and make comes in:
- Docker provides us an environment that help contains the dependencies and make the execution consistent between environments.
- make helps us manage the dependencies and because it is built-in to most OS (except Windows unfortunately) it reduces the needs for extra tool deployment and configuration.
This combo allows developer to run the build on their system with minimum effort. No need to deploy additional packages, if the system has Docker and make then it is good to go.
Windows users: While Windows does come with make, we would recommend that you look at GNU Make.
You can follow the installation instructions from this site: http://gnuwin32.sourceforge.net/packages/make.htm
As we mentioned, Docker provides a pre-built environment which exists within the container, thus avoiding the need to deploy the plethora of tools on the local workstation. Here is the composer task:
.PHONY: composer
composer:
echo ">> Building composer package within Docker container"
docker run --rm -v $(COMPOSER_PATH):/src -v $(DIST_DIR):/dist -w /src node:8.11 sh -c "$(COMPOSER_BUILD_CMD)"
Breaking the docker run command:
- --rm: Remove the container at the end of the build
- -v: Mount the src and dist directory from the git clone folders
- -w: Make the container /src directory the working directory
- node:8:11: Container image with node 8.11 deployed and configured
- sh -c "$(COMPOSER_BUILD_CMD)": The build command to run
As you can see, with minimal configuration the build is now taking place within the container but using the local git clone files and folders. The nice thing about it is that the container will behave the same whether running locally or in our build pipeline.
Why the .PHONY you ask? Makefile is a great but ancient tool. As such, it originally primarily focused on file dependencies.
If someone ever defined a file called build or test, make would consider that the task was up-to-date and do nothing.
.PHONY tells make to not consider those tags as file.
Feel free to explore the remainder of the tasks of the Makefile. Chaincode will be built using a different image (golang:1.9.6) but leverages the same approach.
From a Makefile tasks perspective the following dependencies are defined:
In the next section, we will make use of the make build and make test command to execute our pipeline.