GitHub Actions CI/CD Pipeline for Django API

Nothing teaches you OpenShift better than a broken tutorial... I was recently going through the "Foundations of OpenShift" tutorial by Red Hat, expecting a smooth "Import from Git" experience. Instead, I got a CrashLoopBackOff and a bunch of cryptic logs. It turns out the sample code was quite outdated. It relied on a deprecated tool called powershift-cli that just doesn't work with modern Python S2I images anymore. What I did to fix it: Dug into the logs: Found that the container was trying to run a command that no longer exists (powershift image). Forked the repo: Rewrote the run script to use a standard Django startup. Fixed the "hidden" bugs: Found some syntax errors in the background scheduler and added automatic migrations (no more 500 errors!). Handled the DB: Realized why the blog was empty (ephemeral SQLite storage) and documented it for anyone else trying this tutorial. It took a bit of debugging, but I honestly learned more about OpenShift's build process and S2I than I would have if the "Start" button had just worked. If you're stuck on Tutorial 4, feel free to use my updated repo: https://lnkd.in/dNfjEnGS #OpenShift #DevOps #Django #LearningByDoing #Kubernetes

Just published a new blog on something I recently set up for my Django project — automating tests using GitHub Actions. While building a simple Unit Converter app, I reached a point where manually running tests after every change started feeling repetitive. So I explored how to run them automatically on every push. In the blog, I’ve broken it down in a simple way: * the mental model behind a workflow * how to structure it * and a minimal setup that actually works Nothing overly complex — just a clean starting point if you’re getting into CI. If you’re working with Django (or any Python project), this might help you get your first workflow running. Always open to feedback or better approaches. #Django #Python #GitHubActions #CI #Git #Devops #TestAutomation

https://lnkd.in/dkJRCuRA A full-stack system that lets development teams upload APK binaries, organize them by project, and distribute versioned releases to testers through a dedicated mobile client. In development 🏗️ 🚧 #open #opensource #build #buildinpulic #project #code #mobile #python #django #system

🚀 Implemented a basic CI pipeline using GitHub Actions. On every push, the workflow: Triggers via event-based execution Runs on ubuntu-latest runner Uses a matrix strategy to test across Python 3.8 & 3.9 Checks out repo using actions/checkout@v3 Sets up Python via actions/setup-python@v2 Installs dependencies (pip, pytest) Executes tests using python -m pytest 📁 .github/workflows/first-actions.yaml 🎯 Ensures consistent builds, multi-version compatibility, and automated test validation on every commit (CI). 🔗 Repo: https://lnkd.in/gDpgTwG2 📝 Article: https://lnkd.in/gZwinuZ4 #GitHubActions #CI #DevOps #Python #Automation

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

I recently built a Python-based tool that scans public GitHub repositories to analyze Dockerfile sources and extract base images used across projects. 🔍 What it does: • Parses multiple repositories from a given input source • Locates all Dockerfiles within each repo • Extracts image names from FROM statements • Aggregates everything into a structured JSON output 💡 Why I built this: I wanted to explore how container security and compliance can be improved by tracking trusted base images. This project helped me dive deeper into real-world challenges around scalability, fault tolerance, and clean code design. ⚙️ Tech highlights: • Python for core logic • GitHub repo parsing & file traversal • JSON data structuring • Focus on production-grade practices (error handling, extensibility, maintainability) This was a great hands-on way to strengthen my understanding of containers, automation, and backend design. 🔗 Check it out here: https://lnkd.in/dE5kVceV Would love to hear your thoughts or feedback! #Python #Docker #DevOps #BackendDevelopment #OpenSource #LearningByBuilding

I just published my first Django package: django-magicapi While working on backend projects, I noticed I kept doing the same repetitive setup every time I built APIs with Django REST Framework - writing serializers, viewsets, routers, pagination, permissions, admin registrations, docs setup, etc. At first, I didn’t think much of it because it felt like part of the process. But after repeating it across multiple projects, it started feeling unnecessary. So during my free time, I decided to build something that could automate that process. That turned into django-magicapi - a package that generates production-ready DRF APIs from your existing Django models with one command: python manage.py magicapi --app yourapp It currently handles: Serializers Viewsets Routers API versioning Pagination Permissions Django admin registration Swagger/ReDoc docs Cleanup support This was also my first time publishing a package to PyPI, so I learned a lot while building it - from packaging to making sure the generated code is safe and customizable. Honestly, it feels great to build something that solves a problem I kept facing myself. It’s now live on PyPI and GitHub: PyPI: https://lnkd.in/gir_Y8x6 GitHub: https://lnkd.in/gwFnNq86 If you try it out and run into any bugs, feel free to message me. I’ll keep improving it and adding more features based on feedback. Would love to hear what you think. #Python #Django #OpenSource #BackendDevelopment #DjangoRESTFramework

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

Excited to share something I’ve been working on! I’ve officially published my first Django utility package on PyPI: django-migration-testgen (v0.1.0). As a developer, I’ve always felt that Django migrations are powerful but often under-tested. In real-world projects, especially in large teams and production systems, migrations can silently break things if not properly validated. That’s where this tool comes in. What does it do? It automatically scans your Django apps and generates ready-to-use test files for your migration files, allowing you to confidently verify schema changes, both forward and backward. Why I built this: - Writing migration tests manually is repetitive and often skipped - Migration issues can break production deployments - CI pipelines should validate schema evolution, not just code Key Features: - Auto-discovers all migration files across apps - Generates structured test files per migration - Uses Django’s MigrationExecutor for real execution testing - Supports forward and rollback testing - Dry-run, force overwrite, and custom output directory support - Easy integration into CI/CD pipelines Install & try it: ```bash pip install django-migration-testgen ``` Then just run: ```bash python manage.py generate_migration_tests ``` My goal with this project is simple: make migration testing effortless, scalable, and reliable for Django developers. This is just v0.1.0, and I’m planning to improve it further with smarter test generation, better customization, performance optimizations, and community feedback. If you’re working with Django, I’d love for you to try it out and share your thoughts. Open to feedback, suggestions, and contributions. #Django #Python #OpenSource #SoftwareEngineering #BackendDevelopment #CI #DevOps #Testing #Programming

Improve your project's test coverage with CodeCov integration. Track what code is covered by tests, identify gaps, and ensure quality before merging. Perfect for Python developers working with GitHub actions.