kestra-io

My First Steps into Open Source with Kestra Really enjoyed participating in Hacktoberfest and contributing to Kestra! 🎉 As someone getting started with open source, I found the experience really rewarding. The good first issues made it easy to get started, understand the codebase, and make meaningful contributions. Here's my contribution: kestra#20437 Looking forward to contributing more! 🚀 #Hacktoberfest #KestraHacktober #Kestra

Tests can pass even after a critical check is weakened For @kestra_io Hacktober, I submitted a workflow that: • Compares old and new dbt tests • Runs both against the same flawed data • Blocks a change if the new tests miss an error PR - blueprints#4990 #KestraHacktober

Kestra Hacktober Submission 2026 Excited to share my contribution to #KestraHacktober! I've built an LabRelay: Appwrite custody-audit blueprint with Kestra, a project for tracking water samples from field collection to laboratory receipt. The idea starts with a practical question: when a sample passes between a collector, a courier and a laboratory receiver, can the team follow its recorded journey and identify where something went wrong? LabRelay records sample registration, handoff offers, accepted transfers and laboratory receipts. Claiming a pickup doesn't transfer custody; the recipient must accept the handoff. At the lab, batch receiving records missing samples, unexpected IDs and duplicate scans while preserving the last confirmed custodian. The Kestra blueprint adds a separate, read-only audit of those records. It retrieves an authenticated, organization-scoped export, checks custody history and delivery receipts in parallel, and produces JSON/CSV reports. Findings or incomplete data trigger a failure gate after the reports are saved. A daily schedule can be enabled after setup and verification. One case I enjoyed working through: imagine a lab expects 12 samples but initially receives 11. The original receipt should keep that missing-sample observation. If the twelfth sample arrives later, the audit recognizes its acceptance and classifies the earlier missing observation as resolved, without rewriting history. The aim is to help teams spot inconsistencies and understand what the records actually support. Incomplete exports are reported as inconclusive, so a partial read cannot quietly become a “clean” result. Verification covered real Appwrite authentication, organization isolation and audit outcomes in a separate fictional test project. Four additional Docker scenarios passed their expected outcomes in GitHub Actions using fictional transport. The blueprint PR is ready for review, and I'd love feedback on the concept and implementation! Source and setup: D33PAKsoni/kestra-appwrite-custody-audit · Blueprint PR: blueprints#4988 #Kestra #Appwrite #OpenSource #KestraHacktober

My first open-source contribution to Kestra has been merged! I’m happy to share that my first PR to Kestra has been merged as part of #KestraHacktober! 🔗 PR: kestra#20872 The contribution involved refactoring the TaskArray.vue component's styling, removing Bootstrap utility classes and replacing them with custom CSS while aligning the component with Kestra's design system. It was a great learning experience working with an established open-source codebase, understanding its existing conventions, addressing review feedback, and getting the changes merged. Thanks to the Kestra maintainers for reviewing the contribution and helping me learn along the way! Looking forward to contributing more to open source. #KestraHacktober #OpenSource #Kestra

My 2 PRs got merged in Kestra for #KestraHacktober! >Hi everyone, I wanted to share my contribution to Kestra Hacktober. >I worked on kestra-io/plugin-gcp and got 2 PRs merged. >First one was a bug fix. The Pub/Sub Publish task was not checking the result of publish, so if the topic did not exist it still showed success and the messages were just lost. Now it fails with the proper error. The maintainer tested it with the Pub/Sub emulator also, which helped because I did not have a GCP account with credits to test it myself. >Second one was adding more examples in the docs of the PySparkSubmit task (uploading a script, BigQuery, extra jars, custom container image). >It was my first time contributing to a big open source project. I learned how to read the code, write tests and reply to review comments. Thanks to the Kestra team for reviewing. >PR links: plugin-gcp#719 plugin-gcp#718 >#KestraHacktober

SlothContributor: a local agent that does my issue hunting This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Confession I want to contribute to open source, but I hate the hustle. I used to spend 30 minutes refreshing GitHub, filtering labels, reading long issue threads and guessing which files caused a bug. By the time I understood the codebase, I was too tired to write the fix or the issue was already solved. I wanted to stop searching manually. That became SlothContributor, a local CLI agent that watches my favorite repositories. When a new issue drops, a notification pops up, and the agent has already read the issue, fetched the likely source files and written a structured "Contributor's Hunch" on where to look. What I Built SlothContributor is a local-first, AI-powered CLI agent that watches your favorite open-source repositories for new issues. Instead of manually refreshing GitHub, reading massive issue threads, and trying to understand unfamiliar codebases, SlothContributor automates the entire research phase. The second a new issue drops, it doesn't just notify you. It reads the issue, fetches the relevant source code from the repository, and hands you a structured "Contributor's Hunch" on exactly where to look and how to fix it. - What effort does it save? It eliminates the 30–45 minutes of tedious context-switching, tag-filtering, and codebase archaeology usually required just to start a Pull Request. - Who gets to be a little lazier? Open-source contributors and developers who want to focus purely on the creative part (writing the code) while letting a local AI agent do the heavy lifting of finding, filtering, and analyzing the work. Here is a real run on kestra-io/kestra: !kestra-io/kestra run on area/backend label Issues it has already analyzed are skipped, so I only see new ones. I open my terminal, let the agent do the hunting, and spend my time writing the fix. Demo {% youtube RI2ETJanHFI %} Code {% github flash-source/sloth-contributor %} How I Built It The core is a Python CLI that talks to Ollama, running Google's open-weight Gemma 2 (2B) locally. I chose it because it's fast and runs on my laptop. My first version just asked Gemma to read the issue and suggest a fix. On unfamiliar repos the small model was a confident guesser, and it would invent generic paths like src/App.js or config.json in a Java backend. So I took the guessing away from the model and wrapped it in a suggest, verify, analyze loop: 1. Suggest: Gemma reads the issue and proposes likely file paths. 2. Verify: the Python backend fetches those files from the GitHub API. 3. Analyze: if a file exists, Gemma analyzes the real code alongside the issue. If it returns a 404 because the model made the path up, the agent falls back to the issue text alone and gives a shallower hunch. Gemma is no smarter this way, but a wrong guess now costs a 404 in the log instead of a bad answer. I added MongoDB Atlas for persistent memory (no duplicate analysis, resumable sessions), Plyer for desktop notifications and Rich for the terminal UI. Watch mode python main.py --watch starts the watcher. It checks the repos in my session every 15 minutes and sends a desktop notification when a new issue drops, even if the terminal is minimized. That way I see an issue while it's still fresh instead of stumbling on it days later. Two defaults live in config.yaml: poll_interval_minutes: 15 # how often the watcher checks each repo max_issues_per_scan: 3 # max issues analyzed in one run The cap keeps a scan from looping forever and keeps me inside GitHub's API rate limits. Both values can be changed in config.yaml if you want a faster or wider sweep. Why Does Open Innovation Matter? For this tool, local inference is a requirement. 1. Privacy. The LLM step runs on my machine, so no third-party model provider sees which repos I watch, which issues I pick or what fixes I draft. The tool still calls the GitHub API and stores history in my own Atlas cluster. 2. Cost. An agent that polls continuously and puts full file contents in its prompts would get expensive on a paid API. Running Gemma locally costs nothing per scan. 3. Control. The loop passes intermediate data between steps, and a local model lets me control prompts and output formats without LLM API rate limits or content filters getting in the way. My Agent Session Reasoning runs locally through Ollama. File fetching goes through the GitHub API, and issue history and sessions are stored in my own MongoDB Atlas cluster. I didn't use any hosted agent-tracing tools, so there is no cloud session trace. The logs and hunch history live in MongoDB. The Lazy Payoff I've been contributing to Kestra, and the slow part was never the code. It was getting the context of an issue, finding the exact file involved and working out an approach. That could eat a big chunk of time before I'd written anything, and sometimes I'd comment to get assigned without really knowing if I could solve it. Now the hunch gives me a summary of the issue, where to look and a suggested fix up front. I can tell quickly whether an issue is one I understand and can actually solve, and only then ask to be assigned, instead of leaving a vague comment and figuring it out afterwards. It's a 2B model, so I still read the issue myself, but I start from a direction instead of from zero. This month I've had three PRs merged in kestra-io/kestra (#20389, #20479, #21076). Building SlothContributor made me realize that understanding a problem deeply matters just as much as the time and effort you invest in solving it. The tool doesn't just find issues faster, it forces me to think about what makes an issue actually solvable before I even start coding. For example, when it found the UploadFiles trailing slash bug, the hunch immediately identified the exact YAML properties (filesMap and destination) that needed fixing and even showed me the corrected code structure, saving me from hunting through multiple plugin files. Prize Categories - Best Use of Gemma: used Google's open-weight Gemma 2 (via Ollama) as the core reasoning engine of the suggest, verify, analyze agent, running inference 100% locally. - Best Use of MongoDB Atlas: used Atlas as the persistent memory layer to store analyzed issues, manage interactive sessions and prevent duplicate processing across restarts. Built with 💖 for the Hacktoberfest 2026 Open-Source AI Challenge. Stay lazy, contribute smartly!

We're only 48 stars away from 30k! If you haven't starred Kestra yet and want to sponsor us, star us! kestra-io/kestra

Got two PRs merged today for @kestra_io • Recover deleted S3 objects with approval and SHA256 verification blueprints#4628 #KestraHacktober @arsh_goyal

1/4 My 6th PR across @kestra_io repos is merged! 🎉 This one updates 48 documentation files: clearer logs and task outputs, safer examples for secrets, and an editable approval step. What changed 🧵 @arsh_goyal #Hacktoberfest docs#5984

1/ My third @kestra_io PR this October is merged! 🚀 This one fixes Azure Batch requests failing immediately on HTTP 429 throttling. plugin-azure-lib#40 @arsh_goyal #KestraHacktober #OpenSource t.co