
> "The paradox remains: We build in the dark, hoping to create light."

There's something absurd about our situation as developers in 2025. We're building systems to solve human problems while we're still figuring out what it means to be human. It's like trying to write a manual for something you've never fully understood yourself.

I write code, push commits, ship features. But in quiet moments—usually around 3 AM when debugging some API that refuses to behave—I wonder: What are we really building? And more importantly, why?

The existentialists had it figured out, sort of. Camus wrote about the absurd—our desperate search for meaning in a universe that refuses to give us clear answers. We keep building, keep coding, keep shipping, but the "why" remains frustratingly unclear.

Here's what I've noticed: Technology promises to solve everything, but it amplifies everything instead. Social media was supposed to connect us—now we're more isolated than ever. AI was supposed to make us smarter—instead, it's making us question what intelligence even means.

But maybe that's the point.

Maybe the value isn't in having all the answers. Maybe it's in the questioning itself. Every line of code is a small bet against meaninglessness. Every project is saying, "I believe this matters, even if I can't prove it."

The hard work isn't just learning React or understanding algorithms. The hard work is continuing to create while accepting that you might never understand why you're creating. It's coding with conviction while holding uncertainty.

Most programming philosophy talks about clean code, design patterns, best practices. But the deeper question is: How do you write code that feels true to who you are, not just what the market demands?

I don't have the answer. But I know this: authenticity in code, like authenticity in life, isn't about perfection. It's about being honest about the process—messy, uncertain, human.

The universe doesn't care about your deployment pipeline. But the people using what you build do. And sometimes, that's enough reason to keep going.

The paradox remains: We build in the dark, hoping to create light.


The Paradox of Building in the Dark


> "Why do Java developers wear glasses? Because they don’t C#!” — a classic, but still gold.

Hello fellow developer/human-in-tech!

Have you ever merged PDFs manually like some sort of tech caveman, then built and pushed Docker images like a robot stuck in a time loop?

When you’re merging PDF’s manually but pretend it’s all under control.

Same. But fear not — automation is here to save your sanity and weekends too :).

In this blog, I’ll show you how I built a simple Spring Boot PDF Merger, and then automated the build and Docker push process using Jenkins. It’s easy, it’s powerful, and yes, it might just make you feel like a DevOps wizard.

## Part 1: Meet Our Simple PDF Merger

Imagine your manager drops a folder of 50 PDFs on your desk and says, “Hey man, could you merge these PDFs?”

Or you’re doing an M.Tech in Software Engineering at BITS through WILP, and you need to merge 30–40 lecture PDFs together, and you don’t have time.

That’s when you build this:

### PDF Merger (Spring Boot)
A Spring Boot REST API that merges multiple PDF files into one.

**Tech Stack:**
- Java 17
- Spring Boot
- Apache PDFBox
- Maven

**Sample Endpoint:**
POST `/merge` (with multipart/form-data containing `List<MultipartFile>` as input)

**Sample Controller Snippet:**
<div style={{overflowX: 'auto', width: '100%'}}>

```java
@PostMapping("/merge")
public ResponseEntity<byte[]> mergePdfs(@RequestParam("files") List<MultipartFile> files) {
    ByteArrayOutputStream mergedOutput = new ByteArrayOutputStream();
    PDFMergerUtility pdfMerger = new PDFMergerUtility();
    pdfMerger.setDestinationStream(mergedOutput);
    for (MultipartFile file : files) {
        pdfMerger.addSource(file.getInputStream());
    }
    pdfMerger.mergeDocuments(null);
    return ResponseEntity.ok()
        .contentType(MediaType.APPLICATION_PDF)
        .body(mergedOutput.toByteArray());
}
```

</div>
Easy-peasy. Upload some files, get merged PDF. But now we go full DevOps ninja.

## Part 2: Automating the Docker Build & Push

If you automate a mess, you get an automated mess. But at least it’s a fast mess :)

Let’s automate our Docker builds and image push using Jenkins.

**Our Goal:**
- Build Docker image of our PDF Merger API.
- Tag image based on Git branch.
- Push image to Docker Hub.

**Pre-requisites:**
- Jenkins set up on your machine (use Docker or install natively)
- Docker installed
- Docker Hub account (with repo created)
- Jenkins Docker plugin installed

### Step 1: Dockerfile for Spring Boot PDF Merger
```dockerfile
FROM openjdk:17-jdk-slim AS build
WORKDIR /app
COPY . .
RUN ./mvnw package -DskipTests

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY --from=build /app/target/pdf-merger.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
```
This multi-stage Dockerfile keeps the final image small by copying only the JAR from the build stage.

### Step 2: Jenkinsfile Magic
```groovy
pipeline {
  agent any
  environment {
    IMAGE = "your-dockerhub-username/pdf-merger"
    BRANCH = "${env.GIT_BRANCH}".replaceAll("origin/", "")
  }
  stages {
    stage('Checkout') {
      steps {
        git url: 'https://github.com/your-repo/pdf-merger.git'
      }
    }
    stage('Build') {
      steps {
        sh './mvnw clean package -DskipTests'
      }
    }
    stage('Docker Build & Push') {
      steps {
        sh '''
          docker build -t $IMAGE:$BRANCH .
          echo "Pushing Docker image..."
          docker push $IMAGE:$BRANCH
        '''
      }
    }
  }
}
```
This Jenkins pipeline checks out the repo, builds the project, and pushes the image — all automatically.

### Step 3: Shell Script to Run Anytime
Tired of typing commands? Just run this smart script:

```bash
#!/bin/bash
# Automating Docker build and push with a single command
# Saves you the hassle of doing it manually every time!
DOCKER_IMAGE="your-dockerhub-username/your-repo"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
echo "Building Docker image for branch $BRANCH_NAME..."
docker build -t $DOCKER_IMAGE:$BRANCH_NAME .
echo "Pushing Docker image to Docker Hub..."
docker push $DOCKER_IMAGE:$BRANCH_NAME
if [ $? -eq 0 ]; then
  echo "Docker image successfully pushed to Docker Hub!"
else
  echo "Something went wrong. Docker image push failed."
  exit 1
fi
```
Place this in a `deploy.sh`, give it `chmod +x` and never worry again.

## Step 4: Automate Everything
Now, just run the Jenkins pipeline or execute the shell script and voila — Jenkins takes care of the rest. The Docker image will be built and pushed, and you can rest easy knowing that this task is no longer your responsibility.

## Final Thoughts
Automation is the best thing to happen to DevOps since the coffee break. It’s not just about saving time; it’s about making your workflow smoother, reducing errors, and freeing up mental space for the fun stuff — like chilling with friends or playing games!

Ready to try this out yourself? Give it a shot, and let me know how it goes. Automation is the future, and I am pretty sure you will never go back to the days of manually pushing Docker images.

Haapppyy Codinngg, and may Jenkins always build and push your Docker images without fail!!

To the Jenkins builds running while I sleep. Cheers.

**Repo:**  
Clone it, fork it, break it, automate it.  
[GitHub - nileshkr17/jenkins-pdf-merger](https://github.com/nileshkr17/jenkins-pdf-merger)

And if you liked this blog, give a double tap and do leave a comment!!

**UI:** <a href="https://jenkins-pdf-merger-latest.onrender.com/api/pdf/home" target="_blank" rel="noopener noreferrer">https://jenkins-pdf-merger-latest.onrender.com/api/pdf/home</a>

**API to merge:** <a href="https://jenkins-pdf-merger-latest.onrender.com/api/pdf/merge" target="_blank" rel="noopener noreferrer">https://jenkins-pdf-merger-latest.onrender.com/api/pdf/merge</a>


Blog

The Paradox of Building in the Dark

Automate All the Things: Docker + Jenkins + Spring Boot Made Easy

Archives