Source: Pixabay

Continuous Deploys With Bazel + Github Actions

CI/CD directly from your repo

Shipping code can be a nightmare.

With every code push you need to build, test, and finally upload your artifacts somewhere they can be used.

With the rise of Docker, we’ve had the luxury of papering over minor differences in build and deployment environments—but we still need to pull, build, and push the right artifacts at the right time, respond to when you merge new code, and provision runners to execute all that work.

Services like CircleCI, TeamCity, and Jenkins spun up and thrived by helping us with these problems, but now you can manage the issue right from Github itself.

To show you how, let’s work on a (relatively) simple problem:

We must create a working Docker install of a MediaWiki extension (called Semantic MediaWiki), and deploy it somewhere other people can download it and start using it.

I do that in this repo, which you can use as sort of a starter-kit for problems/codebases you’re working on:

Github Repository: Deploying Semantic MediaWiki

Here are some additional constraints we have, to enforce safety and efficiency of our system:

• Any time we change critical-path code, we should do another deploy
• We should test all changes before deploying
• We should only test+build things that have changed, to save time and resources

Bazel

Bazel is a build and test framework that explicitly graphs out your dependencies. Using its language, you can list out the set of build “targets”—artifacts you’re building that can depend on each other—and “rules” that actually build them.

There are build rules for everything from JavaScript to Python — but here we’ll focus on the ones used to build, manipulate, and deploy Docker containers: rules_docker.

Using these pre-built rules (which we install to our Bazel WORKSPACE), we can configure BUILD.bazel files to do things like pull a container from Docker Hub (or from AWS ECS, or wherever):

container_pull(
    name =…