DEV Community: Mr Bret

From Red to Green: Building a Jenkins Pipeline That Actually Ships Code

Mr Bret — Sat, 22 Aug 2026 10:17:06 +0000

There is a particular kind of satisfaction that comes from watching a pipeline go fully green after an entire day of failures. This is the story of building a Jenkins CI/CD pipeline that pulls code from a private repository, builds a Docker image, pushes it to a registry, and notifies a team on Slack, all without a single manual command once it is done.

The Goal

The brief was simple to state and harder to execute: get Jenkins running locally, connect it to a private GitHub repository, containerize an application, automate the build and push to Docker Hub, and wire up Slack so the team knows the moment something breaks or succeeds. Five stages, one pipeline, zero manual intervention.

Setting the Foundation

Jenkins itself ran inside Docker, which introduced a subtlety many tutorials skip entirely. A container running Jenkins does not automatically know how to run other containers. The Docker command-line tool had to be installed inside that Jenkins container, and the container needed access to the host machine's Docker engine through a mounted socket. Getting this wrong produces a deceptively simple error message: command not found, as if Docker had never existed at all.

The fix required understanding a core Docker concept properly. A running container's state can be captured and turned into a brand new, reusable image using a commit operation. Once the Docker command-line tool was installed and working inside the live container, that state was committed into a new image so the fix would survive even if the container had to be recreated later. This single lesson, that live changes inside a container are temporary unless explicitly saved, turned out to be the most reused
piece of knowledge across the entire project.

Teaching Jenkins to Trust a Private Repository

Public repositories are forgiving. Private ones are not. Connecting Jenkins to a private GitHub repository meant generating a personal access token and registering it as a credential inside Jenkins, then referencing that credential explicitly inside the pipeline definition. One early misstep involved Jenkins looking for a branch called master when the actual repository used main as its default, resulting in a pipeline that could authenticate perfectly and still find nothing to build.

Writing the Pipeline Itself

The heart of the project is a file called a Jenkinsfile, written in a structured syntax that describes a sequence of stages: clone the code, build the image, log into the registry, and push the image. Each stage runs only if the one before it succeeded, and the whole thing is version controlled alongside the application code itself.

Two separate but related problems surfaced here. The first was a simple mismatch: the credential holding the Docker Hub username and password had its username field set incorrectly, causing every login attempt to fail with a message that looked like a network problem but was actually an identity problem. The second, more instructive issue was an access token created with read-only permissions instead of read and write, which allowed the pipeline to authenticate and even build the image successfully, only to fail at the very last step when it tried to push. The lesson here was that success at one stage says nothing about permissions further down the line.

Making the Pipeline Talk

A pipeline that runs silently is only half useful. The final piece was Slack integration, configured through a dedicated plugin and a webhook connected to a real Slack workspace. This introduced its own small trap: a placeholder channel name left unedited in the pipeline file, followed by a second attempt that mistakenly used the workspace name instead of an actual channel. Neither failure was loud. Both failed quietly with a generic notification error, which meant the fix required carefully reading exactly what value Jenkins was trying to send and comparing it against what actually existed inside the Slack workspace.

What Made the Difference

None of these problems were exotic. Every single one had a plain, findable cause once the actual error message was read carefully rather than assumed. A missing command, a wrong username, an underscoped permission, a placeholder value never replaced. Real infrastructure work rarely fails in dramatic, mysterious ways. It fails in small, specific, fixable ways that reward patience and careful reading over cleverness.

By the end, a single push to the main branch triggered an entire chain reaction: code cloned, image built, image pushed to a public registry, and a message landing in Slack within seconds, all without anyone touching a keyboard after the initial commit. That is the entire point of continuous integration and continuous delivery. Not that things never break, but that when they do, the system tells you immediately, and fixing forward becomes the default instead of the exception.

Teaching a Container to Heal Itself: A Real Kubernetes Deployment Story

Mr Bret — Sat, 22 Aug 2026 09:54:37 +0000

There is a moment in every Kubernetes journey where the concept stops being theoretical. It happens the instant you delete a running pod on purpose, watch it disappear, and then watch a brand new one appear in its place without anyone telling it to. This is the account of getting a containerized application running on a real Kubernetes cluster, exposing it properly, securing its configuration, hardening it for failure, and finally teaching an existing pipeline to deploy it automatically.

Starting With the Right Question

The project began with a single running container and a much bigger question behind it: what happens when that container crashes at three in the morning with nobody watching? A single Docker container has no answer to that question. A Kubernetes cluster does.

A local cluster was created using a lightweight tool that runs an entire Kubernetes control plane inside Docker itself, essentially a cluster pretending to be several machines while actually being one laptop. The first real obstacle appeared almost immediately: the application would not start, failing with a connection refused error on a port that seemed correct on paper. Tracing the problem back through the Dockerfile and then into the actual application code revealed the real issue. The port declared in the Dockerfile as documentation had nothing to do with the port the code actually listened on, which was determined by an environment variable with its own internal fallback value. The lesson was blunt and worth repeating: documentation inside a container tells you what someone intended, not what is actually happening.

Giving the App a Front Door

Once the application was running and reachable through a temporary manual tunnel, the next milestone replaced that tunnel with something permanent. This required installing a separate piece of software dedicated entirely to routing incoming traffic by hostname, plus recreating the cluster from scratch with explicit networking rules, since local clusters on certain operating systems do not expose themselves to a browser without that extra step being taken up front. Once done, the application became reachable by a clean, memorable address instead of a raw port number that could change at any time.

Separating Secrets From Code

Real applications need configuration that changes without requiring a rebuild and sensitive values that should never sit inside a public repository. This milestone introduced two new building blocks: one for ordinary settings that could live safely in plain text, and one specifically designed for values that needed to stay hidden. Both were wired into the running application as environment variables, invisible to anyone inspecting the image itself.

The more important lesson here was procedural rather than technical. A real secret value, even a demonstration one, is dangerously easy to commit into version control out of pure habit. The fix involved excluding the sensitive file from tracking entirely and committing only a safe template in its place, a small discipline that matters far more once real credentials are involved rather than placeholder ones.

Proving Resilience Instead of Assuming It

This is where the project stopped being an exercise and started feeling like engineering. Two production behaviors were configured and then, critically, tested rather than trusted on faith. A health check was added that periodically confirmed the application was genuinely responding, not merely that its process happened to still be alive. A second check confirmed the application was ready to accept traffic before ever being sent any. Multiple copies of the application were kept running simultaneously rather than just one.

Then came the proof. One running copy was deleted deliberately, and a replacement appeared automatically within seconds, no human involved. Separately, a continuous stream of requests was aimed at the application while an update was triggered in the background, and every single request succeeded throughout the entire process, with old copies quietly retiring only after new ones had proven themselves ready. Watching that happen live is the single clearest argument for why this technology exists at all.

Closing the Loop

The final piece connected everything back to the automated pipeline built earlier. Rather than manually applying configuration files by hand every time code changed, the existing pipeline was extended with one additional stage that deployed directly to the cluster, using a securely stored set of cluster credentials rather than anything hardcoded.

This stage surfaced the most stubborn problem of the entire project. A configuration file meant to describe how to reach the cluster referenced an address that only made sense from the exact machine that generated it. Once that file was handed to a separate, isolated environment responsible for running the pipeline, that same address pointed nowhere useful. Solving it required understanding how two separate isolated environments could be placed on the same internal network and how to reference one from inside the other using its real internal address rather than a shortcut that only worked locally. It was the kind of problem that looks like magic until you understand exactly one detail, and then becomes completely obvious forever after.

What This Actually Proves

None of this was about mastering every feature Kubernetes offers. It was about taking one application that already existed, already had a working pipeline, and giving it the properties that separate a hobby project from something a team could actually depend on. Reachable by a stable address. Configured without secrets baked into its image. Resilient to individual failures. Updatable without dropping a single request. Deployed automatically the instant new code lands on the main branch.

That combination, more than any single command or configuration file, is what production readiness actually means.