A question I often run into in our trunk-based project at work is:

Can I push onto the current master, or is it broken again?

Yes, one should primarily concern oneself with the root cause of this question even existing and attempt to fix it, but I’m afraid in this project it’s a lost cause. So instead, I’ve taken to the next best thing I could think of: preventing myself and fellow team members from pushing more changes on a red pipeline and making things even worse™.

Introducing the Pipeline Stoplight, or: “Don’t push unless this thing is green”:

Making it was a nice, fairly simple DIY exercise combining the following aspects:

• 3D printing (the casing)
• Electronics (simple circuit design and soldering)
• Arduino programming (reading the pipeline status from the GitLab API via WiFi)

In a previous post, I talked about setting up a Docker and NGINX-based server for running Docker-based web sites and applications. Now, I want to show my process for continuously deploying my apps with a single git push, leveraging the power of GitLab CI.

So I decided to rehost my homepage and a couple other web pages and apps on a new server. And since we’ve been using Docker and Compose for some projects at work, I thought, hey, this could be a neat clean setup for multiple apps hosted on a single machine without installing a ton of local dependencies and managing everything by hand. Here’s the story of how this went down, what I learned along the way, and how you can build the same setup without doing the same mistakes that I initially did.