Automating Security Updates for Prometheus LTS: My First CNCF Contribution

I’ve always loved DevOps, but contributing to an actual CNCF project? That felt like standi
ng at the edge of a pool about to dive in without a previous experience. Yet here I am, sharing how I dove in, learned about LTS, Dependabot, and even survived my first PR without breaking anything or my confidence(phew).

Step 1: Learning About LTS
First, let’s talk Long-Term Support (LTS).

In Prometheus, LTS branches are like the “golden retrievers” of releases: reliable, stable, and supported for a long time (over a year!). They only get:

• Bug fixes
• Security patches
• Documentation updates

…everything else? Nope. Experimental features or new fancy stuff are off-limits. The reasoning is simple: companies rely on these branches for monitoring critical systems. They don’t want surprises that could cause sudden breakdown to their large systems.

I focused on two active LTS branches: release-2.53 and release-3.5. Think of them as my training wheels.

Step 2: Why Security Updates Matter
Security updates aren’t glamorous, but they’re life-saving. Imagine a dependency getting hacked while you’re havaing breakfast with the ex you've been trying to get back with, it’s the worst kind of surprise.

GitHub has a neat helper called Dependabot that automatically opens PRs for vulnerable dependencies. My job? Configure it safely for LTS.
Key rules I followed:

1. Update only Go modules (go.mod) and GitHub Actions
2. Apply updates only to LTS branches
3. Make it security-only, no random feature upgrades
4. Limit PRs to avoid spam: max 2 for Go, 1 for Actions per branch
5. Schedule weekly checks, because daily emails are a nightmare

Step 3: The Contribution Workflow
Here’s how my first PR went down, step by step:

1. Forked the Prometheus repo (because direct access is scary)
2. Cloned my fork locally
3. Created a branch named ci/dependabot-lts-security (naming matters!)
4. Added .github/dependabot.yml with the config I just described
5. Committed my changes with a DCO sign-off (promised I wrote this myself, pinky swear)
6. Pushed the branch and opened a PR

Step 4: What I Learned

• Read the rules first. LTS policies exist for a reason, don’t ignore them.
• DCO matters. Sign-off your commits; it’s a CNCF thing, not a bureaucratic nightmare.
• Automation is powerful. A single Dependabot config can save maintainers hours of toil.
• Initiative is welcome. Maintainers expect new contributors to take the first step.

Honestly, nothing felt cooler than seeing that PR button: “Create Pull Request.” A mix of pride, terror, and adrenaline.

Step 5: The Dependabot Config (Our Tiny Hero)
Here’s what I added(remember, no don't leave a blankspace or a line empty):

version: 2

updates:
  - package-ecosystem: "gomod"
    directory: "/"
    target-branch: "release-2.53"
    schedule:
      interval: "weekly"
    security-updates-only: true
    open-pull-requests-limit: 2

  - package-ecosystem: "gomod"
    directory: "/"
    target-branch: "release-3.5"
    schedule:
      interval: "weekly"
    security-updates-only: true
    open-pull-requests-limit: 2

  - package-ecosystem: "github-actions"
    directory: "/"
    target-branch: "release-2.53"
    schedule:
      interval: "weekly"
    security-updates-only: true
    open-pull-requests-limit: 1

  - package-ecosystem: "github-actions"
    directory: "/"
    target-branch: "release-3.5"
    schedule:
      interval: "weekly"
    security-updates-only: true
    open-pull-requests-limit: 1