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.
The full process looks something like this:sequenceDiagram participant Developer participant GitLab participant Shared CI runner participant VPS Developer->>GitLab: git push GitLab->>Shared CI runner: Trigger build job rect rgb(196,196,255) Shared CI runner->>Shared CI runner: Compile app source end rect rgb(196,196,255) Shared CI runner->>Shared CI runner: Build Docker image(s) end Shared CI runner->>GitLab: Push image(s) to registry GitLab->>VPS: Trigger deploy job rect rgb(196,255,196) VPS->>VPS: Pull image(s) from registry VPS->>VPS: Launch app container(s) end
We are using a standard private GitLab project to host the source code, and push changes there from the local machine via Git. From there, the GitLab CI pipeline takes over, and performs the build and deploy automatically.
GitLab provides a Docker registry for every hosted project, with provisions for the CI jobs to push and pull built container images using automatically provided credentials.Continue reading...
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.Continue reading...
Here I’d like to share a simple Lipo voltage monitoring setup, that I’m using in my Bixler with an FrSky D8R-XP receiver. No sensors or other electronics are required - only a single servo cable and two resistors, total value of about 50c + some soldering.
The FrSky D-series receivers have a great feature: the analogue telemetry inputs, called A1 and A2. On some receivers both are freely accessible (D8R-XP, D8R-Plus), on others the A1 port is hardwired to the internal receiver voltage, but the A2 port is always accessible for external connections (D4R-II). On those ports, a voltage of up to 3.3V can be connected. It is measured internally (0-3.3V = 0-100%) and transmitted via the telemetry uplink to your transmitter. Using a simple voltage divider soldered from two resistors, one can monitor the main battery voltage of a model (or any other voltage).Continue reading...
subscribe via RSS