#100DaysOfDevOps - Day Forty - Four After completing a full Jenkins-based CI pipeline over the last few days, I wanted to take time to talk about GitHub Actions properly before jumping into writing workflows. Today was more about concepts and structure than hands-on work. What I covered: ✅ what GitHub Actions is ✅ why it is one of the most popular CI tools today ✅ how it compares to Jenkins ✅ why GitHub Actions feels simpler when your code already lives in GitHub ✅ why Jenkins is still valuable because it can work across multiple platforms ✅ the role of: GitHub Actions documentation GitHub Marketplace ✅ GitHub Actions concepts like: workflow job runner secrets triggers One thing that really stood out to me today is that the core ideas behind CI tools are usually not different. A lot of the time, what changes is the naming, the interface, the level of setup required, etc. So in many ways, learning Jenkins first made GitHub Actions easier to understand, because I could already recognize the same ideas under different names. When you understand the concept deeply, moving between tools becomes much easier. YouTube Video Link: https://lnkd.in/eBpD3YHN #DevOps #100DaysOfDevOps #GitHubActions #Jenkins #CICD #ContinuousIntegration #Automation #GitHub #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

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

If a change isn’t in Git, it didn’t happen. That’s not something I’m adopting for this build, it’s something I stopped tolerating. In it-re-dc01, everything lives in one place: Ansible roles. Terraform modules. Docker Compose stacks. Helm charts. Docs. Runbooks. ADRs. One repo: it-re-dc01-infra. GitHub Actions runs on a self-hosted runner on re01-mgmt-01. Every push triggers: • ansible-lint • docker compose validation • terraform validate Merges to main trigger applies. Terraform state is not local. It’s stored and secured via Vault-backed workflows. Secrets don’t live in the repo. They’re issued dynamically. Git defines the desired state. Vault secures access to it. GitHub Actions enforces the path to change. No manual changes. No exceptions. I’ve seen what happens without this discipline. At one point, we ran Jenkins where the pipeline configuration lived inside Jenkins itself. When Jenkins went down, the pipelines went with it. We rebuilt them from memory and screenshots and it took two weeks. That wasn’t a tooling issue, it was a process failure. The tool doesn’t matter, the discipline does. No change, no matter how small or urgent, happens outside the pipeline. Because if your system can’t be rebuilt from Git, you don’t control it. #GitOps #PlatformEngineering #CI/CD

Today I learned Basic Workflow Trigger: GitHub Actions Most CI/CD tools feel like you need a PhD to configure them. GitHub Actions is different. It lives right inside your repo, and the setup is just a YAML file. That's it. Here's the theory behind it: GitHub Actions is an automation platform built into GitHub. Every time something happens in your repo — a push, a pull request, a merge — it can trigger a workflow. A workflow is a sequence of jobs that run on virtual machines called runners. The mental model: event → trigger → jobs → steps → actions. The simplest real trigger looks like this: on: push: branches: [ main ] pull_request: branches: [ main ] This tells GitHub: "Run my workflow whenever someone pushes to main OR opens a pull request targeting main." From there you define jobs — install dependencies, run tests, deploy. All automated. All logged. All free for public repos. Why it matters: → No more "it works on my machine" → PRs get automatically tested before merging → Your team gets instant feedback on every change → You build the habit of shipping with confidence I went from zero to a working CI pipeline in under an hour. If you haven't tried it yet — today is a good day to start. What was your first GitHub Actions workflow? Drop it below #GitHubActions #DevOps #CICD #LearnInPublic #100DaysOfCode #Automation #SoftwareEngineering #GitHub #OpenSource #WebDevelopment

🚀 CI/CD with Jenkins vs GitHub Actions — what should you actually use? I’ve been exploring CI/CD while working on backend projects, and one thing became clear — both Jenkins and GitHub Actions solve the same problem, but in very different ways. Here’s how I see it: 🔧 Jenkins Feels like the “full control” option. You can customize almost everything, build complex pipelines, and manage it exactly the way you want. But… you also have to set it up, maintain it, and deal with plugins and servers. ⚡ GitHub Actions Much simpler to start with. If your code is already on GitHub, you just write a workflow file and you’re good to go. No server setup, no extra headache. 🧠 The real difference (in simple terms): Jenkins → more control, more responsibility GitHub Actions → less setup, faster to start 🔥 One important thing I misunderstood earlier: Docker helps you run your app consistently, but tools like Jenkins or GitHub Actions decide: 👉 when to build 👉 when to test 👉 when to deploy 💡 So what should you use? If you’re working on large or complex systems → Jenkins makes sense If you want quick setup and clean workflow → GitHub Actions is a great choice At the end of the day, both are powerful. It just depends on your use case. #cicd #devops #jenkins #githubactions #docker

GitHub >> Jenkins CI Integration While working on a CI setup, assisted in troubleshooting an issue where Jenkins wasn’t triggering builds from GitHub. On reviewing the configuration, identified that the webhook content type wasn’t set to application/json, causing Jenkins to ignore the payload, something that’s easy to miss initially. Small configuration details like content type can break the entire CI flow without obvious errors, it's worth double-checking during setup. #DevOps #Jenkins #GitHub #CICD #Automation #SRE

Pipeline diagram to visualize the flow.It captures the whole lifecycle at a glance: Code → Build → Dockerize → Push → Deploy On the left: Jenkins pipeline stages. On the right: GitHub Actions workflow stages. Both converge at Docker Hub, then deploy into Kubernetes. This way you can revise visually: Blue side = Jenkins (Checkout → Build/Test → Docker → Deploy). Gray side = GitHub Actions (Checkout → Build/Test → Docker → Deploy). Both end in Kubernetes cluster pods + service exposure. It’s the perfect one‑shot view for CI/CD journey. #devops #cicd #githubactions #jenkins

📌 Day 2 of #100DaysOfDevOps — Git + Jenkins = Your first real CI pipeline. Yesterday we installed Jenkins. Today we make it actually do something useful. Why integrate Git with Jenkins? Without this, Jenkins is just a server sitting idle. Connect it to Git and every code push automatically triggers a build — no human needed in the middle. 3 things that tripped me up (so you don't have to): → Always install the Git Plugin in Jenkins first — Jenkins won't talk to GitHub without it. Go to Manage Jenkins → Plugins → Available → search "Git" → Use a Personal Access Token instead of your GitHub password — GitHub deprecated password auth in 2021. Generate one under GitHub Settings → Developer Settings → Tokens → Webhook URL format matters — it should be http://[your-jenkins-ip]:8080/github-webhook/ — that trailing slash is not optional. Missing it = trigger never fires. 3 trigger types every DevOps engineer should know: 1. 🔁 Poll SCM — Jenkins checks your repo on a schedule (H/5 * * * * = every 5 mins). Simple but adds unnecessary load. 2. ⚡ GitHub Webhook — GitHub pushes a signal to Jenkins the moment code is committed. Instant. This is what production teams use. 3. ⏰ Build Periodically — Runs on a cron schedule regardless of code changes. Useful for nightly builds and scheduled tests. Real-world use case: Webhook-triggered pipelines mean your team gets build feedback in under 2 minutes of pushing code — catching broken builds before they reach staging. That's the difference between a reactive team and a proactive one. Quick setup recap: 1. Install Git Plugin in Jenkins 2. Add GitHub repo URL in your Jenkins job 3. Add Jenkins webhook URL in GitHub repo settings 4. Set trigger to "GitHub hook trigger for GITScm polling" 5. Push a commit — watch Jenkins fire automatically ⚡ 📄 Want the full step-by-step installation document? DM me and I'll send it across. What trigger are you using in your current setup — Webhook or Poll SCM? Tell me below 👇 #100DaysOfDevOps #Jenkins #Git #GitHub #CICD #DevOps #Automation #CloudEngineering #AWS #Webhooks

🚀 Day 17 of #100DaysOfDevOps 🚀 Today’s focus was on integrating GitHub with Jenkins CI to achieve fully automated Continuous Integration. ✅ What I learned today: Pulling source code from GitHub to Jenkins CI server ✅ Public repositories ✅ Private repositories (secure access) Configuring automatic CI triggers No manual code checkout Builds start automatically on every change Understanding how Jenkins + GitHub work together to enable true CI 🔑 Key takeaway: CI should be automatic, secure, and event‑driven — manual steps defeat the purpose of DevOps. This learning clearly showed how Jenkins acts as a powerful CI engine when connected properly with GitHub. 📈 Step by step, moving closer to real‑world DevOps pipelines. #DevOps #Jenkins #GitHub #CI #ContinuousIntegration #Automation #DevOpsJourney #100DaysChallenge #LearningEveryDay

🚀 Automate Code Sync Across Repositories with GitHub Actions! Ever needed to push your code to another repository automatically? Whether it's for maintaining a mirror repo, deployment, or syncing across teams — GitHub Actions makes it seamless! 💡 Here’s a quick overview of how you can achieve this: 🔹 Step 1: Create a Personal Access Token (PAT) Generate a token with repo access from your GitHub account. 🔹 Step 2: Add Token as Secret Go to your source repository → Settings → Secrets → Add your PAT (e.g., TARGET_REPO_TOKEN). 🔹 Step 3: Configure GitHub Action Workflow name: Sync to Another Repo on: push: branches: - main <branch name> jobs: sync: runs-on: ubuntu-latest steps: - name: Checkout Source Repo uses: actions/checkout@v3 - name: Push to Target Repo run: | git config --global user.name "GitHub Actions" git config --global user.email "actions@github.com" git clone https://<TOKEN>@https://lnkd.in/djBb7BHB rsync -av --delete ./ target-repo/ cd target-repo git add . git commit -m "Sync from source repo" git push origin main ⚡ Use Cases: Maintain backup repositories Sync code between private & public repos Automate deployments #GitHubActions #DevOps #Automation #CI_CD #SoftwareDevelopment