Samar Akbari’s Post

I built a GitHub Action that reviews pull requests before a human has to. In most CI/CD workflows, a significant amount of time is spent reviewing pull requests that contain avoidable issues - unclear descriptions, missing tests, leftover debug code, or even risky patterns. To address this, I developed truepr, a lightweight GitHub Action that automatically analyzes pull requests and provides a structured quality assessment. It evaluates four key areas: - The code diff (for security risks, bad practices, and missing tests) - The pull request description (clarity, completeness, and intent) - The linked issue (context, reproducibility, and quality) - Contributor history (to provide additional context) Based on this, it generates: - A score from 0 to 100 - A grade (A to F) - A clear recommendation (approve, review, request changes, or flag) The goal is not to replace human review, but to reduce time spent on low-quality pull requests and help teams focus on meaningful feedback. truepr runs entirely within GitHub Actions, requires no external services or API keys, and can be set up in minutes. This is particularly useful for teams and maintainers working with high pull request volumes, where early signal and consistency in review standards are critical. I would welcome feedback from developers, maintainers, and DevOps professionals working in CI/CD environments. Repository: https://lnkd.in/eWRdxEF7 I strongly believe in automation, and that even small, focused tools can significantly reduce friction and save valuable time. #github #opensource #devops #cicd #softwareengineering

Building CI/CD with GitHub Actions: Why It’s a Game Changer 🚀 Stop me if this sounds familiar: You spend hours coding a new feature, push it to production, and—boom—everything breaks because of a small environment mismatch or a forgotten test. We’ve all been there. That’s why a solid CI/CD pipeline isn't just a "nice-to-have" for DevOps enthusiasts anymore; it’s the backbone of professional software engineering. Lately, I've been leaning heavily into GitHub Actions, and here’s why it’s winning: Why GitHub Actions? 🛠️ • Native Integration: No need to manage external servers or third-party plugins. Your automation lives exactly where your code does. • YAML-Based Workflow: Defining a pipeline is as simple as writing a .yml file. It’s version-controlled, readable, and easy to tweak. • The Marketplace: From deploying to AWS/Azure to running specialized security scans, someone has likely already built an "Action" for it. The Real Value 💎 It’s not just about "deploying fast." It’s about: 1. Confidence: Running your test suites on every pull request means catching bugs before they hit the main branch. 2. Consistency: Eliminating "it works on my machine" syndrome. 3. Speed: Automating the repetitive stuff so we can focus on building what actually matters. Whether you're working on a small React project or a massive Java microservice architecture, automating your workflow is the best gift you can give your future self. What’s your go-to tool for CI/CD? Are you Team GitHub Actions, or do you prefer Jenkins/GitLab? Let’s chat in the comments!👇 #SoftwareEngineering #DevOps #GitHubActions #CICD #Automation #WebDevelopment #CodingLife

Two years ago, I was skeptical about GitOps workflows with ArgoCD and Flux for Kubernetes. Today, they're integral parts of my development toolkit. As a developer, I knew the importance of streamlined, automated deployment processes but often struggled with their complexity. That was until I discovered the power of GitOps — the concept of using Git repositories as the source of truth for infrastructure declarations. ArgoCD and Flux have changed the game, allowing for seamless continuous delivery directly onto Kubernetes clusters. Here's a simple ArgoCD application definition to get you started: ``` apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-k8s-app spec: destination: server: https://kubernetes.default.svc namespace: default source: repoURL: 'https://lnkd.in/gQ4MZhEw' path: 'clusters/my-cluster' project: default ``` Working with these tools, I've leveraged AI-assisted development to accelerate coding and deployment processes, making it possible to focus on higher-order problems rather than repetitive tasks. Using such workflows, I can quickly prototype and iterate on new ideas, which significantly boosts productivity and innovation potential. How has your experience with GitOps been, and which tool do you prefer, ArgoCD or Flux? #DevOps #CloudComputing #Kubernetes

Dockerfiles (The Ultimate To-Do List) So far, we’ve talked about the "Shipping Container" (Docker) and the "Recipe" (The Image). But how do we actually write that recipe ? Enter the Dockerfile. 📄 If you’re a DevOps pro, you know that manual setups are the enemy. If you have to tell a teammate, "First install this, then click that, then change this setting," something will go wrong. The Analogy: The Ultimate To-Do List 📋 Think of a Dockerfile as a very strict, step-by-step "To-Do List" for a computer. Imagine you are hiring a chef to bake that cake we talked about yesterday. Instead of standing over them, you leave a note on the counter: FROM: Start with this specific brand of flour (The Base OS). COPY: Take these eggs from the fridge and put them on the table (Your Code). RUN: Mix the ingredients for 5 minutes (Installing Dependencies). CMD: Turn on the oven and start baking (Starting the App). Why is this a game-changer ? No Human Error: The computer follows the list exactly the same way, every single time. Version Control: Since it’s just a text file, I can put it in GitHub. If the app breaks, I can look at the "list" and see exactly what changed. Speed: I can hand this list to a cloud server, and it can "build" my environment in seconds. In DevOps, we don't build servers; we write the instructions so the servers can build themselves. 🛠️ If you’re learning Docker, what was the first "instruction" that tripped you up? For me, it was definitely understanding the difference between RUN and CMD! I’ve actually put together a deep-dive guide on my GitHub! 🚀 I wanted to go beyond the basics, so I’ve documented: ✅ The core instructions (FROM, COPY, RUN, CMD) and more ✅ Common commands you'll use every day 👉 https://lnkd.in/gapUnQhU #DevOps #Docker #InfrastructureAsCode #TechCommunity #LearningInPublic #CloudNative #Automation

Most CI/CD pipelines fail for the same reason — no clear stages. After 4 years in DevOps, here's the multi-stage GitHub Actions pipeline I recommend to every engineer on my team: ━━━━━━━━━━━━━━━━━━━ Stage 1 → Test Stage 2 → Build & tag Docker image Stage 3 → Deploy to Staging Stage 4 → Deploy to Production (with manual approval) ━━━━━━━━━━━━━━━━━━━ 3 things that make this bulletproof: 1️⃣ Use needs: to chain jobs — if tests fail, nothing else runs 2️⃣ Tag images with github.sha — every build is fully traceable 3️⃣ Use GitHub Environments for prod — enforces human approval before anything goes live You don't need a complex tool to do this. A single YAML file in .github/workflows/ is enough to build a production-grade pipeline. Save this post for when you set yours up. What does your CI/CD stack look like? Drop it in the comments 👇 #DevOps #GitHubActions #CICD #Docker #Kubernetes #CloudNative #DevOpsEngineer #SoftwareEngineering

GitOps changed how I think about deployments. Here's the mental model: Before GitOps: ❌ SSH into server → pull code → restart service → pray ❌ Jenkins pipeline pushes directly to cluster ❌ "Who deployed what?" — nobody knows After GitOps: ✅ Git is the single source of truth ✅ ArgoCD watches the repo and syncs automatically ✅ Every deployment is a Git commit — auditable, reversible ✅ Multi-cluster? Just point ArgoCD at different directories Key decisions I made: 1. Mono-repo for manifests (simpler than multi-repo for our scale) 2. ArgoCD for app deployments, FluxCD for infra components 3. Automated image tag updates via CI → Git commit → ArgoCD sync If you're starting with GitOps, start with ArgoCD + a single cluster. Don't over-engineer day one. Save this for later ♻️ #GitOps #ArgoCD #FluxCD #Kubernetes #DevOps #EKS #Kubernetes #AWS #CICD #PlatformEngineering #GitOps #Terraform #ArgoCD #CloudEngineering #SRE #DevSecOps #BackstageIO #InfrastructureAsCode #GitHub #Docker #DevOpsCommunity #TechCareers #LearningInPublic #BuildInPublic

🗓️ Day 28/100 — 100 Days of AWS & DevOps Challenge Today's task: a developer has in-progress work on a feature branch but one specific commit is ready and needs to go to master right now, without dragging the rest of the unfinished work along. This is exactly what git cherry-pick is for. # Find the commit hash on the feature branch $ git log feature --oneline # abc5678 Update info.txt ← this one # Switch to master and cherry-pick it $ git checkout master $ git cherry-pick abc5678 # Push $ git push origin master One commit. Surgically applied. Feature branch untouched. 1. Why not just merge the feature branch? - The feature branch has in-progress commits code that isn't tested, isn't ready, and would break things on master. git merge feature brings ALL of it over. Cherry-pick takes only what's ready. 2. When this pattern matters in production: - A critical bug fix lands on a development branch. You can't merge the whole branch, there are half-finished features alongside the fix. You cherry-pick the fix onto master and onto any active release branches. This is how security patches get backported across multiple versions in open source projects. Same concept, same tool. The command to find a commit by message when you don't have the hash handy: $ git log --all --oneline --grep="Update info.txt" Saves time when the branch has many commits and you're looking for one specific one. Full breakdown on GitHub 👇 https://lnkd.in/gVHV9qPc #DevOps #Git #VersionControl #CherryPick #GitOps #100DaysOfDevOps #KodeKloud #LearningInPublic #CloudEngineering #CICD #Hotfix

A few weeks ago I had highlighted (https://lnkd.in/dT6uTsS7) some recent non-AI development in the DevOps space and eBPF (kernel level observability) was one of them. Here is GitHub using it effectively to hook into DNS lookups and network connections to help with identifying circular dependencies in deployments and providing better, more observable deployments. I think it is still in a nascent phase and probably lacks a layer or two of abastraction for wider adoption but what a great demostration of the capability. Worth a read.

🗓️ Day 29/100 — 100 Days of AWS & DevOps Challenge Today's task wasn't just Git — it was the full engineering team workflow that makes collaborative development actually safe. The requirement: Don't let anyone push directly to master. All changes must go through a Pull Request, get reviewed, and be approved before merging. This is branch protection in practice. Here's the full cycle: Step 1 — Developer pushes to a feature branch (already done) $ git log --format="%h | %an | %s" # Confirms user commit, author info, commit message Step 2 — Create the PR (Log into GIT) - Source: story/fox-and-grapes - Target: master - Title: Added fox-and-grapes story - Assign a user as reviewer Step 3 — Review and merge (log into GIT as reviewer) - Files Changed tab — read the actual diff - Approve the PR - Merge into master Master now has user story. And there's a full audit trail of who proposed it, who reviewed it, who approved it, and when it merged. Why this matters beyond the task: - A Pull Request is not a Git feature - it's a platform feature. Git only knows commits and branches. The PR is a Git/GitHub/GitLab construct that adds review, discussion, approval tracking, and CI/CD status checks on top of a branch merge. When companies say "we require code review before anything goes to production," this is the mechanism. When GitHub Actions or GitLab CI runs tests on every PR — this is where that hooks in. When a security audit asks "who approved this change?" — the PR has the answer. The workflow is identical across Git, GitHub, GitLab, and Bitbucket: push branch → open PR → assign reviewer → review diff→ approve → merge → master updated → branch deleted Full PR workflow breakdown on GitHub 👇 https://lnkd.in/gpi8_kAF #DevOps #Git #PullRequest #CodeReview #Gitea #BranchProtection #100DaysOfDevOps #KodeKloud #LearningInPublic #CloudEngineering #GitOps #TeamCollaboration

Open Source Series- Week 2 Hundreds of products are being built right now that can't deploy without Vercel, Railway, or Render. Not because those are the right tools. Because writing a Dockerfile, setting up CI, and configuring Kubernetes from scratch is genuinely painful and these platforms make that pain disappear instantly. So teams take the easy path. And quietly end up locked in. Pricing changes. Limits get hit. Migrating out becomes a project in itself. The real problem was never deployment. It was that the underlying infrastructure knowledge required to deploy on your own terms was too high a tax to pay on every new project. So I built LaunchKit. Run launchkit init - it detects your stack and scaffolds everything. Run launchkit generate - it produces your Dockerfiles, CI pipelines, and Kubernetes manifests. You own every file it generates. No platform dependency. No lock-in. And if you ever outgrow it, launchkit eject leaves you with clean standalone files. Engineering time should go toward building product — not toward reinventing deployment infrastructure every single time. GitHub: https://lnkd.in/e3cdTSfa #opensource #devops #docker #kubernetes #softwaredevelopment