In this article I will teach how to use
Docker
containers as a development workspace using a real word example. I will go through multipleDev Ops
related topics. However, this is still an example that I have had the opportunity to work on during my open-sourcing journey.
What do we want to achieve?
One of the wonderful open source projects that I have got the opportunity to help in is the One Programming language . The goal of this project is to create a programming language named One. To build the project and run tests you must have a list of hard to install and configure dependencies on your machine, e.g. Make
, LLVM
, etc. Moreover, we wanted to make it easy for developers to get involved and contribute easily in the project. That's why we considered having a docker image to build the code and run tests as priority. Hence, we created this beautiful image for our organization.
In this article I am going to show you how we made it and also how you can make you own development image.
Build the Docker
image
First things first, we need to build the image. Indeed there is nothing special in this section, because we will only write a Dockerfile
for our image. Yet, what make this image special are the pieces of software that will include. Generally, you ought to setup packages required to run your project and your tests, along side with a version control system like git
. As far as I am concerned, I included the following packages in my lightweight alpine
base image:
FROM alpine:latest
LABEL The One Programming Language
# LLVM version
ARG LLVM_VERSION=12.0.1
# LLVM dependencies
RUN apk --no-cache add \
autoconf \
automake \
cmake \
freetype-dev \
g++ \
gcc \
libxml2-dev \
linux-headers \
make \
musl-dev \
ncurses-dev \
python3 py3-pip \
git
Next I setup the reaming packages, like LLVM
and pre-commit
. This last is a powerful framework for managing and maintaining multi-language pre-commit
hooks. It is an important addition to your open source project. Since Git hook
scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.
# Build and install LLVM
RUN wget "https://github.com/llvm/llvm-project/archive/llvmorg-${LLVM_VERSION}.tar.gz" || { echo 'Error downloading LLVM version ${LLVM_VERSION}' ; exit 1; }
RUN tar zxf llvmorg-${LLVM_VERSION}.tar.gz && rm llvmorg-${LLVM_VERSION}.tar.gz
RUN cd llvm-project-llvmorg-${LLVM_VERSION} && mkdir build
WORKDIR /llvm-project-llvmorg-${LLVM_VERSION}/build
RUN cmake ../llvm \
-G "Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="X86" \
-DLLVM_ENABLE_PROJECTS="clang;lld" \
-DCMAKE_BUILD_TYPE=MinSizeRel \
|| { echo 'Error running CMake for LLVM' ; exit 1; }
RUN make -j$(nproc) || { echo 'Error building LLVM' ; exit 1; }
RUN make install || { echo 'Error installing LLVM' ; exit 1; }
RUN cd ../.. && rm -rf llvm-project-llvmorg-${LLVM_VERSION}
ENV CXX=clang++
ENV CC=clang
# pre-commit installation
RUN pip install pre-commit
Now as everything is perfectly configured, you can copy your project directory, build the code, and run your tests while showing significant logs:
# Work directory setup
COPY . /One
WORKDIR /One
# CMake configuration & building
RUN mkdir build
RUN cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ -H/One -B/One/build -G "Unix Makefiles"
RUN cmake --build ./build --config Debug --target all -j 6 --
# Change directory to build
WORKDIR /One/build
# Running example input.one
RUN ./lexer ../src/input.one log
RUN cat log
# Running tests
RUN ./lexer_test
RUN ./parser_test
RUN ./argument_test
# Tests Dashboard
CMD ctest --output-on-failure
Deploy it to DockerHub
To do so, you will need a DockerHub
account. Yet, only your account username and credentials are required. As we are going to deploy it using GitHub Actions
. Similarly to pre-commit
, using GitHub Actions
, or any CI\CD
tool is a good Dev Ops
practice. Especially that we are going to configure our image to run pre-commit
hooks, build the code, run tests, and deploy it the new image to DockerHub
. In fact, you will do very minor changes to the following GitHub Workflow
to use it in any other project.
Let's begging by configuring the GitHub Workflow
that will run on every push or pull request:
name: Dockerize One Programming language
on:
push:
branches: [master]
pull_request:
branches: [master]
jobs:
build-deploy:
name: Build and Publish Docker image
runs-on: ubuntu-latest
Next, we will add steps to configure needed GitHub Actions
to deploy to DockerHub
. Particularly, you won't need any other GitHub Actions
. Because, you already have a Dockerfile
with all the prerequisites!
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
We shall continue by Sign into our DockerHub
account:
- name: Login to DockerHub
uses: docker/login-action@v1
with:
username: ${{secrets.DOCKER_HUB_USERNAME}}
password: ${{secrets.DOCKER_HUB_PASSWORD}}
Before we go to the next step you need to add secrets.DOCKER_HUB_USERNAME
and secrets.DOCKER_HUB_PASSWORD
to your Github
repository:
Finally, publish your new image named onelangorg/one:latest
to DockerHub
:
- name: Build and Push to DockerHub
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: onelangorg/one:latest
Don't forget to configure cache so that you won't need to go with all the unnecessary configuration steps everytime. Also, this will decrease the run time dramatically. In my case without cache the run time is about two hours, but with cache it often doesn't surpass one minute and a half!
cache-from: type=registry,ref=onelangorg/one:latest
cache-to: type=inline
Consequently, you will cerate a Docker
repository in your docker account.
Use it as a Workspace
In this section you will need to pull the docker
image form DockerHube
have VSCode
with Remote-Containers
installed:
This awesome extension admit of getting into the Docker
container itself, by opening a VSCode
window inside it.
After Opening the new window attached to your container you can open the development directory:
And Here you go you have a workspace configured and ready to use!
Conclusion
Now that you come to the end of this article, you can see how important to use Docker
, DockerHub
, and GitHub Actions
. As well as how easy to use are they. These technologies helps developers to be more productive and not bother with the repetitive configuration of the workspace. On every pull request, we get an updated Docker
image with a clean code and successfully run tests thanks to pre-commit
, Github Actions
, and cache.
Top comments (0)