In this challenge you will prepare Continuous Integration & Continuous Delivery (CI/CD) setup for Ethereum contracts. The idea is:
- Developer uses GitHub or GitLab to manage his Ethereum (Solidity) code;
- Each commit to the remote repository triggers CircleCI 2.0 CI/CD job;
- The job runs a Docker container prepared by you, which will use Myth tool to test commited version of Ethereum code;
- In case of errors the CI/CD job should fail with error, otherwise succeed; the current build status will be shown in the developer's Git repository with status badges.
Detailed RequirementsYour solution itself should be prepared to be managed by Git (thus, all documentation in Markdown format), and it will consist of two parts (sure place them into separate sub-folders):
- Dockerfile for creation of Docker container, with Ubuntu and Myth tool installed. This container will be published to Docker Hub, so that our CircleCI jobs can pull and use it for the CI/CD process.
Dockerfile should have appropriate comments. Also in this folder we’ll need Markdown documentation on what is this Dockerfile for and how to publish / update Docker container to the Docker Hub (this documentation is intended for anybody new to your solution, who wants to update the CI/CD process you have created; a developer who just want to use your solution as is for his Ethereum code won’t have to touch the Docker part);
- CircleCI 2.0 setup files (YAML), and any scripts to be executed in the container, that developer may want to modify (i.e. use your best judgement to decide, what logic can be included into the container at the creation time, because a developer user will unlikely need to modify it; and any logic that a developer may want to tune / change often, because it is really specific to his Ethereum project, should go here).
This should be accompanied with Markdown documentation for developer user, covering how to setup this for his project. We assume that he should be able to copy the content of this subfolder into his code, make any necessary changes in the provided YAML files and scripts (commenting/uncommenting some sections, probably changing some constants), then make any necessary settings in his GitHub / GitLab repo, and the CircleCI dashboard, and it should be ready to use. All instructions for the standard setup should be given directly into the document (you may only refer to 3rd party, i.e. GitHub / GitLab / CircleCI documentation only for advanced settings, all basic setup instructions should be given directly in your document).
You must provide instructions both for GitHub or GitLab integration. Don’t forget about instructions on adding status badges to the user’s repository with Ethereum code. It should look like tutorial, you may use the code from here and/or here to demonstrate it in action and as an example in the tutorial.
Note that CircleCI allows to cache build assets to reuse in future builds. We expect you to investigate whether a proper caching can significantly speed-up incremental CI/CD builds. If the speed-up turns out to be insignificant (say ~10% of build time, you may to not use the caching; however if some competitor will use the caching and his solution will handle CI/CD process about twice or more times faster than yours, you’ll be scored down for not using the caching).
The root folder of your solution should contain README.md file, that outlines the purpose and organization of the project, and directs users to documents in the subfolders.
As usual, if you have any doubts / suggestions how to solve the problem better, if done somewhat differently from what is written above, don’t hesitate to discuss in the challenge forum.
ScoringThe challenge will be judged by community reviewers using the standard code scorecard.
The major requirements:
- The setup described above is provided
- All requested documentation is provided
- Solution works as expected
- The caching, if somebody shows that caching is important
In this section of the scorecard the technical details should be accounted (quality of Dockerfile, YAML, and any other scripts you provide).
This section will be used to score for better and worse done documentation. Quality of documentation is very important for us in this challenge. While documentation point in the major requirements stays for documentation covering all points, here we can better score how well, from the reader point of view, each point is covered.