Samuel KHARITONOFF’s Post

🚀 From Writing Code → To Automating Everything! Recently, I worked on my project WealthLens and took a big step forward — I implemented my first CI/CD pipeline using GitLab. At first, I didn’t even understand why CI/CD is important… but while building it, everything started making sense. Here’s what I learned 👇 🔹 Every push is automatically verified No more “it works on my machine” — GitLab builds, runs, and tests everything automatically. 🔹 Real errors taught me real lessons Faced issues like: Maven not found Wrong environment setup Missing configurations And fixed them step by step. 🔹 Team collaboration became clear Worked with branches, commits, and Merge Requests — just like real companies. 🔹 Confidence boost 🚀 Now I know how real-world development works: Write → Push → Validate → Merge 💡 Biggest takeaway: CI/CD is not just automation… it’s a safety system for your code. 🔗 Project Link: https://lnkd.in/d6HgAD2C Tech Stack: Java | Spring Boot | Python (Flask) | GitLab CI/CD | Git Next step: Deployment 🌐 #CICD #GitLab #JavaDeveloper #SpringBoot #LearningByDoing #FullStackJourney

Ever wonder how CLI tools are actually built? I've been using them forever - git, npm, docker, vercel. I often type commands into a terminal without considering the underlying processes. So I decided to build one myself. 👉 Here's what I've learned so far: A CLI is essentially a program that reads arguments from your terminal, runs logic, and writes back to stdout. That's the whole idea. What makes it feel "real" is the layer on top - argument parsing, subcommands, flags, error handling, and help text. In Python, a library called Click handles all of that. You define commands as functions, decorate them, and Click does the rest, including auto-generating --help output, validating inputs, and managing subcommand routing. What surprised me most is how much of a CLI is just Python packaging. The reason you can type "git" instead of "python -m git.cli" is purely a setup.py / pyproject.toml entry point. One config line maps a command name to a function. That's it. 👉 CLIs are how developers talk to tools. Every deployment pipeline, every dev toolchain, every automation script runs on CLI commands. Understanding their construction alters your approach to reading documentation, debugging issues, and designing your own tools. 👉 Still in the early stages. But this is one of those things where building it yourself makes you understand every CLI you've ever used slightly differently. More updates as I go. #Python #CLI #DevTools #LearningInPublic #BuildInPublic #SoftwareEngineering

🚀 Containerising a Flask Application with Docker I recently worked on a simple project where I containerised a Flask application using Docker. The goal was to understand how applications can run consistently across different environments — a core concept in DevOps. ⚙️ What I Built A lightweight Flask web application A Dockerfile to package the application A containerised setup that runs the app with a single command 🔄 How It Works The application is built into a Docker image and then run inside a container. This ensures that all dependencies, configurations, and runtime environments stay consistent — regardless of where the application is deployed. 🧰 Tech Stack Python (Flask) Docker Git & GitHub 💡 Key Takeaway This project helped me clearly understand how containerization simplifies deployment and eliminates environment-related issues. Instead of worrying about system differences, everything runs inside an isolated container. 🚀 What’s Next The next step is to extend this project by integrating CI/CD tools like Jenkins or GitHub Actions and exploring container orchestration with Kubernetes. 📌 Final Thought Before automation and scaling, mastering containerisation is essential — and this project was a solid step in that direction. #DevOps #Docker #Flask #Python #Containerization #SoftwareDevelopment #BackendDevelopment #CloudComputing #Linux #GitHub #LearningJourney #TechProjects #DeveloperLife #Automation #OpenToWork bongoDev

CI/CD pipelines play a critical role in today's cloud-native software development cycle. They are the backbone of how developers build, test, and deploy code. But CI/CD security is often overlooked. Blindly. Usually, due to lack of awareness. Not intentionally.  But attackers don't care whether misconfigurations were introduced purposely or not. They simply exploit them. KONTINUERLIG, a GitHub Actions challenge from Hack.lu 2025 that I participated in, is a perfect example of how that plays out. It chained three distinct attack primitives to extract a secret from a private repository. Each one exploiting a misconfiguration pattern you'd find in a real production pipeline. Here's how the chain works: 🔗 Stage 1 - Heredoc Injection via pull_request_target A workflow used pull_request_target + untrusted checkout (classic "pwn request" pattern). By crafting filenames that terminate a bash heredoc prematurely, I injected LD_PRELOAD into the GitHub Actions environment, then leveraged artifact poisoning and Python module shadowing to achieve code execution with pull-requests: write permissions. 🔗 Stage 2 - Docker Build Context Escape >> A second workflow ran docker build ./docker/ with contents: write permissions. A single symlink (ln -s . docker) redirected the build context to the repository root, exposing .git/ inside the container. From there, the embedded GITHUB_TOKEN was used to push arbitrary commits directly to the main branch. 🔗 Stage 3 - Secret Exfiltration via Problem Matchers GitHub Actions redacts secrets in logs - but Problem Matchers execute before the redaction mechanism. By committing a matcher.json to main and using ::add-matcher:: as the commit message (echoed by the workflow), I registered a regex pattern that captured the flag before masking occurred. None of these primitives are exotic. Pull_request_target misuse, overly permissive GITHUB_TOKEN scopes, Docker build context assumptions, and trust in secret redaction as a last line of defense - these show up in production pipelines. Full writeup on my blog (link in the comments section) 👇 #AppSec #hacklu #CICD #GithubActions #OffensiveSecurity #PenetrationTesting #SecDevOps #CTF

Excited to share my latest open-source project: Diff Guardian (v0.1.3) is now live on npm! Here's the problem every engineering team quietly lives with: Standard git diff operates on text. It sees added lines and removed lines. It has zero understanding of your code's actual structure, its function signatures, interface contracts, type hierarchies, or export boundaries. So when someone removes a required parameter, tweaks an exported interface, or mutates a return type, git doesn't blink. The merge goes through. The push succeeds. And the breakage ships silently. Plain-text diffs and standard code reviews often miss these issues, and they only surface later when they break the CI/CD pipeline or worse, reach production. That's why I built Diff Guardian- Impact-Aware API Contract Enforcement Engine. Under the hood, it compiles Tree-Sitter grammars to WebAssembly and runs them in a process to parse every modified file into a full Abstract Syntax Tree. A custom AST Mapper extracts structural signatures, functions, interfaces, enums, type aliases, generics, visibility modifiers, and feeds them into a Classification Engine that evaluates diffs against production-hardened rules covering parameter mutations, return type changes, generic constraint shifts, enum member removals, and more. But detection alone isn't enough. You need to know the downstream impact. So Diff Guardian includes a JIT Import Scanner and Call-Site Tracer that lazily builds a dependency graph across your repo. When a breaking change is detected, it resolves every barrel re-export, follows every import chain, and tells you exactly which files and line numbers will fail, before you ever hit merge. Powered by Tree-sitter WASM grammars parsing at ~100k lines/sec, full impact analysis completes in under 100ms, even across repos with tens of thousands of files. What you can do with Diff Guardian: → Compare branches → Scan staged/uncommitted changes → Trace symbol dependencies → Auto-post structured reports on every GitHub PR → Prevent broken code with pre-push & pre-merge hooks Supports TypeScript, JavaScript, Python, Go, Java, and Rust out of the box. This isn't a linter. It's not a type checker. It's a structural contract enforcer that sits between your version control and your deployment pipeline, ensuring that API surface changes are intentional, visible, and accounted for. 🌐Website & Docs: https://diffguardian.space ⭐ GitHub: https://lnkd.in/g5evGguk 📦 npm: https://lnkd.in/gDE7z-zJ This is just v0.1.3. There’s still a long way to go. If you’ve faced silent API regressions or care about developer tooling, I’d appreciate your help. Contributions of any kind, features, rules, docs, or issues are welcome. Let’s build better guardrails for the code we ship. #OpenSource #DeveloperTools #TypeScript #JavaScript #Python #Rust #go #Git #CICD #GitHubActions #WebAssembly #SoftwareEngineering #APISafety #CodeQuality #DevOps #BuildInPublic #NPM

🚫 What is .gitignore & Why You Should Use It When working with Git, not every file belongs in your repository. That’s where .gitignore comes in — it tells Git which files and folders to ignore. 🔹 Why use .gitignore? Avoid uploading sensitive data (API keys, passwords) Keep your repo clean (no unnecessary files) Ignore system files & dependencies 🔹 How to create a .gitignore file In your project root, create a file named: .gitignore 🔹 Common Examples # Ignore node modules node_modules/ # Ignore environment files .env # Ignore Python cache files __pycache__/ *.pyc # Ignore logs *.log # Ignore OS files .DS_Store Thumbs.db 🔹 How it works Git will automatically ignore the files listed in .gitignore when you run: git add . 💡 Pro Tip: If a file is already tracked by Git, adding it to .gitignore won’t remove it. You’ll need to untrack it first: git rm --cached filename Using .gitignore properly makes your projects cleaner, safer, and more professional 💯 #Git #GitHub #Programming #Python #WebDevelopment #Developers #CodingTips # .gitignore - tells Git what NOT to track .venv/ .env __pycache__/ *.pyc .DS_Store

Continuous learning isn't just a goal—it’s a necessity. In the ever-evolving world of software development, staying stagnant isn't an option. I’ve spent the recent months diving deep into the Spring Boot ecosystem, mastering advanced techniques and building robust, scalable applications. Beyond the frameworks, I’ve doubled down on my Object-Oriented Programming (OOP) fundamentals to ensure my code isn’t just functional, but clean, maintainable, and efficient. To put these skills into practice, I recently completed a TaskManager Application. It’s built with a focus on advanced Spring features and solid OOP principles. Check out the project here: 👉 frontend-https://lnkd.in/gs5VS46u 👉 backend-https://lnkd.in/gT7KJYVK I’m excited to keep pushing boundaries and building more. If you're into Spring Boot or backend dev, let’s connect! #SpringBoot #Java #OOP #WebDevelopment #SoftwareEngineering #Backend #LearningNeverStops #GitHub

GitHub Actions Simplified: Breaking Down a CI/CD Pipeline 🚀 Ever felt like YAML files were written in a secret language? If you're looking to automate your workflow, GitHub Actions is the powerhouse you need to master. This visual guide breaks down a standard Java/Maven CI/CD pipeline into bite-sized pieces. Here is the core logic of what’s happening: 1. The Trigger (on:) Everything starts with an event. In this example, the pipeline wakes up whenever someone pushes code or opens a pull request to the main branch. No manual intervention required! 2. The Build & Test Job Before code goes live, it needs to be validated. • Environment: It runs on ubuntu-latest. • Steps: It checks out your code, sets up the Java environment (JDK 11), builds the app with Maven, and runs automated tests. If a test fails here, the process stops—saving you from breaking production. 3. The Deployment Job (needs: build) This is the "CD" part of CI/CD. Notice the needs: build tag? This creates a dependency, ensuring deployment only happens if the build and tests were successful. • It packages the app into a Docker image. • It uses docker-compose to refresh the running services. 4. Notifications Once the heavy lifting is done, the pipeline sends an automated email to the team. Success is confirmed, and everyone stays in the loop without checking logs. The Bottom Line: Automation isn't just about saving time; it’s about creating a repeatable, reliable process that catches bugs early and deploys with confidence. What’s your favorite GitHub Action trick or marketplace plugin? Let’s chat in the comments! 👇 #GitHubActions #CICD #DevOps #SoftwareEngineering #Automation #CodingTips #TechCommunity

Yesterday, I joined the Open Source Friday live stream featuring Serena from GitHub. It was an insightful deep dive into collaborative development and real-world problem-solving. Watching experts navigate a codebase in real-time offers a perspective you can't get from documentation alone. It highlights the critical thinking, the debugging logic, and the architectural "why" behind every decision. My main takeaways from the session: Community-Driven Growth: Open source is about collective intelligence and making technology inclusive. The Learning Curve: Continuous exploration remains a constant, even for seasoned developers. The Reality of Building: Exploring the Serena project (https://lnkd.in/d9EKMbCn) was a great reminder that every polished feature begins with iterative, sometimes complex steps. For those looking to go beyond watching and start using it, here is how to get Serena MCP running on your machine: 1. Installation on Windows The simplest way to run Serena MCP is using uvx. It allows you to run Python packages on the fly without a complex local setup: Ensure Python is installed. Use uvx in your terminal to execute the package directly as per the documentation. This keeps your environment clean while giving you full access to Serena's capabilities. 2. Setup in VS Code (using GitHub Copilot) Once the server is ready, you can integrate it into your workflow in seconds: Add a configuration file: Create a .vs code folder in your project and add an mcp.json file. Register the server: Use the "Add Server" button or the command palette to link your MCP server. You can run it via a local command or even a Docker image. Interact: Once connected, your tools will appear directly in the Copilot chat, allowing you to query the Serena codebase or perform tasks through the MCP protocol seamlessly. A big thank you to Serena and the GitHub team for promoting the "Build in Public" mindset. 🚀 Are you currently contributing to any open-source initiatives or exploring MCP tools in your IDE? I’d love to hear about your experience in the comments. #OpenSource #GitHub #SoftwareEngineering #MCP #VSCode #SerenaProject #WebDevelopment #LearningInPublic #TechCommunity

Day 11 - "git push" and your tests run, your linter checks, and your app deploys. No clicking. No SSH. Just a YAML file and GitHub does the rest. 🚀TechFromZero Series - GitHubActionsFromZero This isn't a Hello World. It's a real CI/CD pipeline for a real Django API: 📐 git push → GitHub Actions → flake8 lint → pytest (3 Python versions) → deploy to Render 🔗 The full code (with step-by-step commits you can follow): https://lnkd.in/dEwEy9jn 🧱 What I built (step by step): 1️⃣ Project scaffold — Django JSON API with health check, headlines, and search endpoints 2️⃣ First workflow — on:push trigger, ubuntu-latest runner, checkout + setup-python 3️⃣ pytest test suite — 17 unit tests with mock data (no real API calls in CI) 4️⃣ CI test stage — pytest with coverage reporting, fail the build on any error 5️⃣ flake8 linting — catch style issues and bugs before tests even run 6️⃣ Matrix testing — test across Python 3.10, 3.11, 3.12 in parallel 7️⃣ Dependency caching — pip cache with hashFiles(), cut install from 30s to 5s 8️⃣ PR checks — block merging until CI passes (branch protection rules) 9️⃣ Deploy workflow — separate workflow, curl to Render deploy hook, main only 🔟 Secrets + environments — GitHub Secrets for credentials, environment protection rules 1️⃣1️⃣ CI badge + full README — status badge, architecture diagram, setup guide 💡 Every YAML file has detailed comments explaining WHY, not just what. Written for any beginner who wants to learn GitHub Actions by reading real workflows — with full clarity on each step. 👉 If you're a beginner learning CI/CD, clone it and read the commits one by one. Each commit = one concept. Each file = one lesson. Built from scratch, so nothing is hidden. 🔥 This is Day 11 of a 50-day series. A new technology every day. Follow along! 🌐 See all days: https://lnkd.in/dhDN6Z3F #TechFromZero #Day11 #GitHubActions #CICD #Django #Python #Pytest #DevOps #Automation #LearnByDoing #OpenSource #BeginnerGuide #100DaysOfCode #CodingFromScratch