Web3 Meets DevOps: Pipeline, Build Stage | by Donovan Brown | Jun, 2022

Web3 needs DevOps

Part 5 — Building a DevOps pipeline for the Ethereum blockchain

Photo by Caspar Camille Rubin on Unsplash

In the previous article of this series, Web3 Meets DevOps: Creating the Initial Structure of Pipeline, I laid out the initial structure of the pipeline. In this article, I will complete the build stage where I compile, test, and package the artifacts.

To make editing the pipeline YAML easier, I installed the Azure Pipelines extension for VS Code. This adds syntax highlighting and autocompletion.

I created a new branch named “blog/part5” for this article.

git checkout -b blog/part5

To complete the build stage, I added the steps element on line 11, below the compile_test job. The first step calls npm install to install Truffle.

Step to install Truffle

I added a displayName to make the step easier to recognize in the pipeline logs.

With Truffle installed, I could compile and test the contracts. Because I configured the test command to output a results file as discussed in Web3 DevOps: Part 1 — Compiling and Testing, I also publish the test results.

At this point, I decided to check in my code and see if everything worked as expected. To my surprise, the test step failed!

Azure Pipeline with failed test step
Test contracts failed

The logs of my build showed the following information:

Build logs showing test failure
Test failure logs

After some research, I discovered the error was a result of adding the development node to the truffle-config.js file in Web3 Meets DevOps: Deploying Contracts. By default, the truffle test command uses a built-in test network.

However, once you define a development network, it switches to using that network. This is fine for local development where I run Ganache locally, but in the first stage of my pipeline, I want to run the tests using the default test network.

To accomplish this, I updated the truffle-config.js file. Because the configuration file is executed JavaScript code, I changed the logic to dynamically define the development environment if an environment variable is set. In the environment variable named DEV_NETWORK, I placed the IP address of the Ganache instance.

When I ran it locally, I set it to When running in the Dev environment of the pipeline, it will be set to the IP of the Ganache instance running in the cloud. In the build stage of the pipeline, this environment variable will not be set, resulting in the tests being executed using the built-in test network.

I decided to use dotenv to read the environment variables, so I installed it and saved it as a dependency in my root folder.

npm install --save-dev dotenv

With my dependencies in place, I updated the truffle-config.js file to match the code below:

Next, I updated my .gitignore file to ignore any future .env files I create. My root level .gitignore file now looks like this:

Then I committed and pushed my code to test my changes.

Contract test results
Contract test results

With my tests passing, I moved on to packaging and publishing my contracts and contract tests as artifacts. Here’s the code:

Tasks to package and publish artifacts
Azure Pipelines artifacts page showing contract artifacts
Contract artifacts

Packaging these files as artifacts will make them available to other stages in my pipeline.

With the contracts out of the way, I moved to the frontend. The goal was the same: compile, test, package, and publish as an artifact. Notice I set the CI environment variable on the test step to true. Alternatively, you could set that variable for the entire stage or pipeline.

Tasks for front end
1*HrcbWrtuFfaA Sg1QuyBBQ
Frontend test results and artifact

The final project was the Azure Function API.

Tasks for API
1*752rq8yb yQ9nkAQKuyFUA
API artifact and test results

With all the projects compiled, tested, and packaged as artifacts, I will develop the Infrastructure as Code (IaC) in the next article.

Editor: Chelsea Brown
Technical Review: Brian Benz

News Credit

%d bloggers like this: