Faris Jamil’s Post

GitHub Branch Protection: Advanced Rules for Status Check Dependencies Master advanced branch protection configurations that go beyond basic reviews. Learn to set up dependent status checks, automatic review dismissal, and linear history enforcement for enterprise-grade code quality control. Read the full how-to guide: https://lnkd.in/gB3fSePc #ITTips #Productivity #DevOps #GitHub #TechTips #OpenSource #SoftwareDevelopment #BranchProtection #CodeQuality #GitWorkflow

GitHub's merge queue silently rewrote main branch history on April 23rd. The pattern: PR shows a +29 / -34 diff. Reviewed, approved, queued. What lands is +245 / -1,137 — thousands of lines of already-shipped code quietly removed. Every merge after that stacks on the broken history. UI shows nothing wrong. GitHub says 2,800 PRs out of 4 million. One company reported 200+ on its own. Pick a number. The part nobody's saying out loud: for history to get overwritten like this, something is force-pushing to main behind the scenes. Branch protection apparently doesn't apply to GitHub itself. Worth thinking about what else moves through that path silently. The deeper issue isn't the bug. Bugs happen. The issue is that "distributed version control" became a single vendor's merge button for most of the industry, and the merge button lied for a day. Git itself was fine the whole time. It always is. I run my own Gitea. Recommend it. #GitHub #Git #DevOps #Gitea #SelfHosted #SoftwareEngineering

Hey Techies 👋, DevOps Reality Check When even GitHub becomes unreachable.... Today’s task looked simple push code, trigger my Jenkins pipeline, and continue working on my Docker setup. But instead, I hit this: 👉 fatal: unable to access 'https://github.com/...' 👉 Could not resolve host: github.com At first, it felt like a blocker. But in DevOps, these “small” errors often teach the biggest lessons. After digging deeper, I realized the issue wasn’t with Git or Jenkins it was a DNS/network issue on my remote server (via SSH). How I solved it: - Checked internet connectivity on the remote machine - Verified DNS configuration in /etc/resolv.conf - Restarted network services - Ensured proper nameserver (like 8.8.8.8) was set - Re-tested using ping github.com And finally… connection restored, code pushed, pipeline back on track Key takeaway: 𝐍𝐨 𝐦𝐚𝐭𝐭𝐞𝐫 𝐡𝐨𝐰 𝐚𝐝𝐯𝐚𝐧𝐜𝐞𝐝 𝐲𝐨𝐮𝐫 𝐂𝐈/𝐂𝐃 𝐩𝐢𝐩𝐞𝐥𝐢𝐧𝐞 𝐢𝐬, 𝐞𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 𝐝𝐞𝐩𝐞𝐧𝐝𝐬 𝐨𝐧 𝐭𝐡𝐞 𝐛𝐚𝐬𝐢𝐜𝐬 𝐧𝐞𝐭𝐰𝐨𝐫𝐤𝐢𝐧𝐠 𝐚𝐧𝐝 𝐜𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐯𝐢𝐭𝐲. This was a reminder that DevOps isn’t just automation… It’s also patience, debugging, and understanding systems from the ground up. Have you ever been stuck because of something as simple as DNS? #DevOps #Jenkins #Docker #GitHub #CICD #Troubleshooting #LearningInPublic #WomenInTech #CloudComputing

GitHub's 2026 Security Roadmap for Actions is setting a new standard for secure CI/CD practices. With a focus on secure defaults and enhanced observability, GitHub is paving the way for more robust and secure software development workflows. The roadmap emphasizes the integration of security features directly into the CI/CD pipelines, which is crucial for maintaining the integrity of software delivery processes. By adopting these new security measures, developers can ensure that their workflows are not only efficient but also secure by design. For those managing CI/CD pipelines, this roadmap is a call to action to evaluate and integrate these upcoming features. Staying ahead in security means adapting to these changes early and ensuring your development processes are aligned with the best practices outlined by GitHub. For more details on GitHub's security roadmap, you can view the full announcement on their official blog. #GitHubActions #Security #CICD #DevOps #SoftwareDevelopment

A lot of developers rely on GitHub every single day, but the moment you ask them how it truly differs from GitLab, the answers often get blurry. And honestly, I understand why, on la surface they look similar, yet they don’t serve the same vision at all. GitHub has become the place where the world writes code together. Backed by Microsoft and fueled by a massive open-source community, it’s built for speed, simplicity, and collaboration. Actions, Codespaces, Dependabot… everything is designed to help teams move quickly and stay focused on building. GitLab, on the other hand, follows a completely different philosophy. It’s not just a code platform, it’s a full DevSecOps environment. CI/CD is built-in, security tools are native, governance is centralized, and you can even self-host it with the open-source edition. Many companies choose it because they want one platform to manage everything from planning to deployment. So the question isn’t really “which one is better?”. It’s more like “which vision matches the way you work?”. One focuses on velocity and massive adoption. The other focuses on deep integration and full end-to-end control. If you’ve used either platform in your projects, I’d really love to hear your experience. What actually makes a difference in your daily workflow? And what would you pick again if you had to start from scratch? Your insights will definitely help others who are still trying to choose the right tool. #GitHub #GitLab #DevOps #DevSecOps

A lot of developers rely on GitHub every single day, but the moment you ask them how it truly differs from GitLab, the answers often get blurry. And honestly, I understand why, on la surface they look similar, yet they don’t serve the same vision at all. GitHub has become the place where the world writes code together. Backed by Microsoft and fueled by a massive open-source community, it’s built for speed, simplicity, and collaboration. Actions, Codespaces, Dependabot… everything is designed to help teams move quickly and stay focused on building. GitLab, on the other hand, follows a completely different philosophy. It’s not just a code platform, it’s a full DevSecOps environment. CI/CD is built-in, security tools are native, governance is centralized, and you can even self-host it with the open-source edition. Many companies choose it because they want one platform to manage everything from planning to deployment. So the question isn’t really “which one is better?”. It’s more like “which vision matches the way you work?”. One focuses on velocity and massive adoption. The other focuses on deep integration and full end-to-end control. If you’ve used either platform in your projects, I’d really love to hear your experience. What actually makes a difference in your daily workflow? And what would you pick again if you had to start from scratch? Your insights will definitely help others who are still trying to choose the right tool. #GitHub #GitLab #DevOps #DevSecOps

GitHub just announced a complete architectural rebuild of Actions—and the reason why matters more than the features themselves. The catalyst? Agentic development. 71 million job executions later, it became clear: the infrastructure wasn't built for how we're working in 2025. AI-powered workflows, GitHub Copilot agents, and autonomous DevOps pipelines demanded a fundamental rethink. Here's what the rebuild enables: → YAML anchors for configuration reuse (finally matching GitLab and Bitbucket) → 10-level reusable workflow nesting with federated credentials → Each workflow now carries its own identity—enabling secure credential scaling without duplicating secrets → Complete removal of the 10GB cache limit The strategic insight here: Reusable workflows with federated credentials allow centralized deployment pipelines where downstream teams consume workflows without managing separate credentials. That's a massive win for enterprise security and governance. But the bigger story is this: Agentic DevOps isn't just changing how we write code. It's forcing us to reimagine our entire infrastructure stack—compute, caching, identity, and orchestration. GitHub is preparing for a world where AI agents run your pipelines. Are your systems ready? More details: https://lnkd.in/gDhG2kJF #AgenticDevOps #GitHubActions #DevOps

Hard freeze: the system won't let you merge. Soft freeze: "please don't merge." Guess which one works. Every "Slack-message-and-hope" freeze I've seen eventually gets violated. Sometimes by a well-meaning engineer who missed the thread. Sometimes by a contractor who isn't even in the channel. Sometimes by the merge queue itself, which doesn't read Slack at all. The fix isn't better communication. It's a required status check that says no. NoShip turns your freeze into a GitHub check that blocks merges at the source — across every repo, every branch, every environment. Policy becomes control. No honor system required. #CodeFreeze #DevOps #GitHub #SRE #PlatformEngineering #DeploymentSafety #EngineeringLeadership #ChangeControl

🚀 Scaling on GitHub: From Script to Enterprise Moving from a solo project to a large-scale enterprise environment isn’t just about more code—it’s about managing complexity. When hundreds of developers contribute, "git push" isn't enough. You need system-level governance. Here are the 10 pillars of GitHub at scale: Structure: Choose between a Monorepo (unified flow) or Polyrepos (team independence). Storage: Use Git LFS to keep your repository slim by offloading large binary files. Gates: Implement Branch Protection—no code hits production without passing CI/CD. Ownership: Define a CODEOWNERS file to automate review assignments to the right experts. Governance: Use Rulesets to apply security guardrails across every repo in your organization. CI/CD: Scale your automation with Matrix Builds to test multiple OS versions simultaneously. Performance: Deploy Self-hosted Runners for faster, more secure automation pipelines. Security: Leverage Dependabot and Secret Scanning to catch vulnerabilities before they’re exploited. Analysis: Use CodeQL to treat your code as data and find deep-seated logic flaws. Roadmaps: Align your team with GitHub Projects (v2) for high-level visibility beyond just code. The goal? Shift from "writing code" to "building systems." 🛠️ #DevOps #DevSecOps #GitHub #SoftwareEngineering #CloudNative #SystemDesign #OpenSource

I started by building the infrastructure for my To-Do App using Terraform and Ansible, and then added a full CI/CD pipeline using GitHub Actions and Docker. What it does: First, Terraform creates the server (VPC, Subnets, ElasticIP, Security Groups, etc) and network automatically. Then Ansible sets up the server, Git Runner, installs Docker, and prepares the environment. After that, CI/CD handles the deployment. When I push code to GitHub main branch, GitHub Actions builds the app, creates a Docker image, and pushes it to Docker Hub. After that the server pulls the latest image, stops the old container, and starts the new one automatically. It also keeps only the latest 5 images to save space. Why this is useful: This removes manual work, reduces errors, and makes deployment faster and more reliable. What I learned: This project helped me understand how infrastructure setup and deployment automation work together in real DevOps. Special thanks to my supervisor Sampath D. for the guidance and support. #DevOps #Terraform #Ansible #Docker #GitHubActions #CICD #InfrastructureAsCode #CloudComputing #Automation #SoftwareEngineering #DevOpsJourney #LearningByDoing #TechProject #PortfolioProject #FutureEngineer #AWS #CloudArchitecture #OpenToWork #ITStudent #ContinuousDeployment #antlerfoundry