When you build tons of kernels every day like my team does, you look for speed improvements anywhere you can. Caching repositories, artifacts, and compiled objects makes kernel builds faster and it reduces infrastructure costs. Need for speed We use GitLab CI in plenty of places, and that means we have a lot of gitlab-runner configurations for OpenShift (using the kubernetes executor) and AWS (using the docker-machine executor). The runner’s built-in caching makes it easy to upload and download cached items from object storage repositories like Google Cloud Storage or Amazon S3.

Buildah and podman make a great pair for building, managing and running containers on a Linux system. You can even use them with GitLab CI with a few small adjustments, namely the switch from the overlayfs to vfs storage driver. I have some regularly scheduled GitLab CI jobs that attempt to build fresh containers each morning and I use these to get the latest packages and find out early when something is broken in the build process.

My team at Red Hat depends heavily on GitLab CI and we build containers often to run all kinds of tests. Fortunately, GitLab offers up CI to build containers and a container registry in every repository to hold the containers we build. This is really handy because it keeps everything together in one place: your container build scripts, your container build infrastructure, and the registry that holds your containers. Better yet, you can put multiple types of containers underneath a single git repository if you need to build containers based on different Linux distributions.

Environment variables are easy to add to OpenShift deployments, but a more secure way to add these variables is by referencing a secret.

This post is the second installment in the series of What’s Happening in OpenStack-Ansible (WHOA) posts that I’m assembling each month. My goal is to inform more people about what we’re doing in the OpenStack-Ansible community and bring on more contributors to the project. July brought lots of changes for the OpenStack-Ansible project and the remaining work for the Newton release is coming together well. Many of the changes made in the Newton branch have made deployments faster, more reliable and more repeatable.