Simplifying GitHub Actions with NERV-Actions

#100DaysOfDevOps - Day Forty - Six Today I continued working on the GitHub Actions version of my CI pipeline. The focus was on moving from the workflow skeleton into actual execution, one stage at a time, while testing and troubleshooting along the way. What I worked on today: ✅ created the .github/workflows/ci.yaml file ✅ pushed it to GitHub and confirmed the workflow was triggered ✅ verified that the checkout stage worked ✅ observed how GitHub Actions provisions a runner automatically ✅ added the backend test stage ✅ set up Python on the runner ✅ installed pip ✅ confirmed the backend test/lint stage ran successfully After that, I moved into the image build stage and started setting up: Docker-related steps GitHub secrets for Docker authentication environment variables for image names and tags That part came with multiple errors, including: wrong field names wrong action version invalid Docker tag formatting mismatched secret references And honestly, I’m glad it happened that way. Because one thing this journey keeps reinforcing is: CI/CD is not learned by only watching clean demos. It is learned by writing, testing, failing, correcting, and understanding why the workflow failed. So even though the image build stage is still being resolved, today still felt like strong progress because the earlier stages are now working, and the workflow is taking shape properly. Big takeaway: The deeper skill is not avoiding errors, it is learning how to read them and move forward with clarity. YouTube Video Link: https://lnkd.in/eDVKJz8d #DevOps #100DaysOfDevOps #GitHubActions #CICD #ContinuousIntegration #Docker #Automation #GitHub #YAML #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

#100DaysOfDevOps - Day Forty - Eight Up until now, I had been tagging my Docker images in GitHub Actions using the workflow run number. It worked, but I wanted something more meaningful and more traceable. So today I moved toward using the Git commit hash as the image tag. What I worked on today: ✅ revisited why image tagging strategy matters ✅ moved from using the workflow run number to using github.sha ✅ explored GitHub Actions contexts and built-in variables ✅ checked commit hashes from both GitHub and git log ✅ learned why the full commit hash is too long to use directly ✅ extracted only the first few characters of the hash ✅ stored that shortened value as a workflow variable ✅ reused that variable across the image build, scan, and push stages ✅ observed how GitHub Actions automatically cleans up the runner after execution A better CI pipeline is not only about making it run but also about making its outputs easier to understand, track, and roll back when needed. I did hit another issue near the end around the backend image reference format, so there is still a bit of troubleshooting to finish. But overall, this was a strong step toward making the workflow more production-friendly. YouTube Video Link: https://lnkd.in/eM458884 #DevOps #100DaysOfDevOps #GitHubActions #Docker #ImageTagging #CICD #ContinuousIntegration #GitHub #Automation #CloudEngineering #LearningInPublic #TechdotSam

We cut our deployment time from 47 minutes to 9 minutes using GitHub Actions. Here is what actually moved the needle. Not the flashy stuff. The boring stuff. 1. We stopped running the full test suite on every commit. Using pytest -k with changed-file detection, we ran only relevant tests. Saved ~11 minutes immediately. 2. We parallelised Docker layer caching properly. We were using cache, but pulls were still sequential in our workflow. Fixing that shaved off another 6–7 minutes. 3. We removed a manual approval gate that had been sitting in our pipeline since a production incident in 2022. No one on the team of 5 engineers could explain why it still existed. 4. We built a shared base image for our microservices instead of each service installing the same ~350MB of dependencies separately. The bottleneck in your pipeline is almost never where you think it is. Profile it first. Then fix it. What is the biggest time sink in your current pipeline? #CICD #DevOps #PlatformEngineering #GitHubActions #Docker

Day 39 of #90DaysOfDevOps 🚀 Today I focused on understanding CI/CD before building pipelines. Here’s a simple pipeline I designed: 🔹 Code pushed to GitHub 🔹 Build → Install dependencies & compile 🔹 Test → Unit & integration testing 🔹 Dockerize → Build & push image 🔹 Deploy → Run container on staging server 💡 Key takeaway: “It works on my machine” is not enough — CI/CD ensures consistency across environments. Next step → Implementing this using GitHub Actions ⚡ #DevOps #TrainWithShubham #CICD #GitHubActions #LearningInPublic

⚙️ #PythonJourney | Day 158 — CI/CD: Automation That Saves Lives Added GitHub Actions to the project. Now every push runs tests automatically. If something breaks, I know immediately. If it passes, I have confidence to deploy. 14 tests running in 44 seconds. Green or red. No surprises. What I learned: → CI/CD isn't optional, it's essential → Catching bugs early beats finding them in production → Automated testing gives peace of mind → GitHub Actions is simple but powerful It's simple, but it changes everything. #DevOps #GitHub #CI #CD #Automation #Backend #Testing

⚡ CI/CD mindset unlocked Explored GitHub Actions today and it just makes sense now 👇 🔹 🚀 Push → Auto Build/Test/Deploy 🔹 ⚙️ Easy workflows, powerful impact 🔹 🧠 Less manual work, more focus 🔹 📈 Consistent pipeline = fewer bugs 🔹 🔄 Thinking in systems, not steps Still exploring, but this is a solid shift in how I build 💻 #CI_CD #GitHubActions #DevOps #LearningInPublic

🚀 𝙄 𝙎𝙩𝙤𝙥𝙥𝙚𝙙 𝙐𝙨𝙞𝙣𝙜 𝙁𝙪𝙡𝙡 𝙂𝙞𝙩 𝘾𝙡𝙤𝙣𝙚 𝙞𝙣 𝙋𝙧𝙤𝙙 𝘿𝙚𝙗𝙪𝙜𝙜𝙞𝙣𝙜 — 𝙃𝙚𝙧𝙚’𝙨 𝙒𝙝𝙮 Most engineers default to: 👉 git clone <repo> (full clone) But during a recent production issue, I realized something powerful 👇 🔴 Scenario: Latest deployment → ❌ Failed Previous version → ✅ Working Instead of pulling the entire repo history, I used: 👉 git clone --depth 2 <repo> ⚡ Why this worked: Gave me just the last 2 commits 🔸 Allowed quick comparison: 🔹 What changed? 🔸What broke? 🔹Saved time ⏱️ (no heavy clone) 🔸Faster root cause identification 💡 Pro Tip: If needed, you can always expand later: git fetch --deepen=5 git fetch --unshallow 🎯 Key Insight: “Debug present → go shallow Debug past → go deep” 🔥 One-liner I now follow: 👉 For production failures after a recent deployment, start with --depth 2 to compare the last known good and failing commit—then deepen history only if needed. Below image for an example with comparison of full clone vs shallow clone with last 1 commit. full clone gave 4402 objects whereas shallow gave 360 of the last latest commit. Meet you in next writeup 🤝 #DevOps #AzureDevOps #Git #SRE #CloudEngineering #Debugging #Productivity #Azure

50 reruns for GitHub Actions workflows feels a bit tight, doesn't it? Makes you really think about why a workflow failed in the first place. Time to get serious about debugging! #DevOps #CI/CD

Most Go developers are using GitHub Actions wrong — and it’s costing them speed, reliability, and clarity. I wrote this to break that pattern. The problem isn’t YAML. It’s the way we think about CI/CD. In this article, I walk through: – Why most pipelines become messy and fragile – The mindset shift from “scripts in YAML” → “clean orchestration” – How to structure Go workflows for speed, simplicity, and production reliability – What senior engineers do differently when designing CI Good CI isn’t about making builds pass. It’s about making systems trustworthy. If your pipeline feels slow, confusing, or brittle — this is for you. Read here: https://lnkd.in/dtYNh43T #golang #githubactions #devops #backend #softwareengineering #cicd

If you’ve been in the DevOps game for a while, chances are you’ve crossed paths with Jenkins. It was a trailblazer in CI/CD automation, but let’s face it—those days are behind us. Maintaining Jenkins in 2023 can feel like wrestling with a dinosaur: outdated UI, finicky plugins, and constant server babysitting. Enter GitHub Actions: the modern CI/CD solution that’s baked right into GitHub itself. Whether it’s native GitHub integration, eliminating infrastructure headaches, or leveraging the marketplace of pre-built actions, GitHub Actions delivers simplicity and scalability where Jenkins struggles. Plus, it’s all managed in YAML—clean, lightweight, and easy to debug. That’s not to say Jenkins doesn’t still have its place. For legacy systems, non-GitHub repositories, or custom infrastructure needs, it may remain the right tool for the job. But for most teams using GitHub, it’s time to make the switch. What’s holding you back from adopting GitHub Actions, or if you’ve already made the move, what’s been your experience so far? #DevOps #CICD #GitHubActions