Forem: Hitesh Sachdeva

Release 0.4 Final: Reflecting on My Open Source Contributions for release 0.4

Hitesh Sachdeva — Fri, 12 Dec 2025 16:14:07 +0000

Overview

Over the past two weeks, I worked on two meaningful contributions to open-source projects. This final blog post summarizes my work, discusses the results, and reflects on what I learned throughout Release 0.4.

Project	Issue	Type	PR Status
OpenCTI	#13594	New Feature	PR #13608 - Submitted
Nextcloud Desktop	#9197	Bug Fix	PR #9206 - Discussion with Maintainer

Contribution 1: OpenCTI - Configurable Export Timeout

The Problem

OpenCTI's data export feature had a hardcoded 20-minute timeout. For organizations with large threat intelligence datasets, exports would fail before completing. Administrators had no way to change this without modifying the source code.

Issue: https://github.com/OpenCTI-Platform/opencti/issues/13594

My Solution

I made the export timeout configurable through platform settings:

Added platform_export_timeout field to the GraphQL schema
Modified workToExportFile() to read timeout from settings
Implemented a fallback to 20 minutes for backward compatibility
Updated all function callers to handle the async changes

Pull Request: https://github.com/OpenCTI-Platform/opencti/pull/13608

Technical Highlights

// Read timeout from platform settings with fallback
const settings = await getEntityFromCache(context, ENTITY_TYPE_SETTINGS);
const timeout = settings.platform_export_timeout || 20; // Default 20 minutes

Result

The pull request is currently under review. I have responded to initial feedback and am awaiting final approval from the maintainers.

Contribution 2: Nextcloud Desktop - Folder Icon Fix

The Problem

On Windows, custom folder icons were being reset every time Nextcloud synced files. Users who organized their folders with custom icons would lose them after every sync operation.

Issue: https://github.com/nextcloud/desktop/issues/9197

Root Cause

Windows custom folder icons require:

A desktop.ini file inside the folder
The FILE_ATTRIBUTE_SYSTEM flag on the folder

The Nextcloud CFAPI wrapper was overwriting file attributes during sync, losing the FILE_ATTRIBUTE_SYSTEM flag.

My Solution

I modified cfapiwrapper.cpp to preserve existing file attributes before updating placeholders:

// Preserve existing file attributes (especially FILE_ATTRIBUTE_SYSTEM)
const auto currentAttributes = GetFileAttributesW(path.utf16());
if (currentAttributes != INVALID_FILE_ATTRIBUTES) {
    metadata.BasicInfo.FileAttributes = currentAttributes;
}

Pull Request: https://github.com/nextcloud/desktop/pull/9206

Result

The pull request is currently under review. I have responded to initial feedback and am awaiting final approval from the maintainers.

Skills I Developed

Technical Skills

GraphQL Schema Design: Learned how to extend GraphQL schemas and propagate changes through a large application
Windows API Programming: Gained hands-on experience with GetFileAttributesW() and the Cloud Files API (CFAPI)
C++ Development: Navigated and contributed to a large C++ codebase for the first time
Caching Systems: Understood how platform settings and caching work in enterprise applications

Soft Skills

Code Reading: Improved my ability to understand unfamiliar codebases quickly
Technical Communication: Wrote clear PR descriptions and responded professionally to review feedback
Project Navigation: Learned to find relevant code in large repositories with hundreds of files

Challenges and How I Overcame Them

Challenge 1: Complex Build Environments

Nextcloud Desktop required Qt6, KDE libraries, and other dependencies. Setting up the build environment on Windows was difficult.

Solution: I focused on understanding the code thoroughly and ensuring my changes were correct based on existing patterns, even without a full local build.

Challenge 2: Understanding New APIs

Both the Windows CFAPI and OpenCTI's caching system were completely new to me.

Solution: I spent time reading official documentation, studying existing code patterns, and tracing through function calls to build understanding.

Challenge 3: Following Project Conventions

Each project had its own coding style, PR templates, and contribution guidelines.

Solution: I carefully read contribution guides and studied recent merged PRs to match the expected format and style.

Key Takeaways

Read before you write. Understanding existing code patterns is essential before making changes.
Backward compatibility matters. Always provide sensible defaults so existing users are not affected.
Small changes can have big impact. Both my contributions were relatively small in terms of lines of code, but they solved real problems for real users.
Open source is collaborative. Engaging with maintainers and responding to feedback is just as important as writing good code.
Challenge yourself. Working on C++ and Windows APIs pushed me outside my comfort zone, but that is where the most learning happens.

What I Would Do Differently

If I were starting Release 0.4 again, I would:

Set up build environments earlier to allow for local testing
Start exploring issues sooner to have more time for complex contributions
Engage more with the project communities through discussion forums or chat channels

Conclusion

Release 0.4 was a significant step forward in my open-source journey. I moved beyond simple fixes to contribute a new feature and a meaningful bug fix to two established projects. The Pr's are progressing through review.

More importantly, I gained confidence in my ability to contribute to unfamiliar codebases and technologies. Whether it is JavaScript, GraphQL, C++, or Windows APIs, the core skills of reading code, understanding systems, and communicating clearly remain the same.

I am proud of what I accomplished and excited to continue contributing to open source in the future.

# Release 0.4 Week 2: Fixing a Windows Bug in Nextcloud Desktop Client

Hitesh Sachdeva — Fri, 12 Dec 2025 02:09:15 +0000

Moving to a New Challenge

After submitting my pull request for OpenCTI, I wanted to take on something different for the second half of Release 0.4. I decided to explore the Nextcloud Desktop Client, a popular open-source file synchronization tool used by millions of people worldwide.

Nextcloud allows users to sync files across devices while maintaining control over their data. The desktop client is a C++ application with deep integrations into Windows, macOS, and Linux. This was a significant step outside my comfort zone since most of my experience has been with JavaScript, not C++.

The Bug I Found

While browsing the Nextcloud issues, I came across Issue #9197:

https://github.com/nextcloud/desktop/issues/9197

The problem was straightforward from a user's perspective: custom folder icons on Windows were being reset every time Nextcloud synced files.

On Windows, users can set custom icons on folders by right-clicking → Properties → Customize → Change Icon. Many people use this to visually organize their files. But with this bug, every sync would wipe out those custom icons and replace them with the default folder icon.

Understanding the Root Cause

Before fixing anything, I needed to understand how Windows handles custom folder icons. After some research, I learned that Windows uses two things:

A hidden desktop.ini file inside the folder containing the icon path
The FILE_ATTRIBUTE_SYSTEM flag set on the folder

Both must be present for the custom icon to appear. If either is missing, Windows shows the default icon.

I then explored the Nextcloud codebase to find where this attribute might be getting lost. The relevant code was in:

src/libsync/vfs/cfapi/cfapiwrapper.cpp

This file handles the Windows Cloud Files API (CFAPI), which Nextcloud uses for virtual file support. I discovered that during sync operations, the code was setting file attributes to default values (FILE_ATTRIBUTE_NORMAL or FILE_ATTRIBUTE_DIRECTORY) without preserving existing attributes like FILE_ATTRIBUTE_SYSTEM.

My Fix

The solution was to read the current file attributes before updating them, and preserve any existing flags. I modified three functions in cfapiwrapper.cpp:

1. `updatePlaceholderState()`

Added code to read and preserve existing attributes:

// Preserve existing file attributes (especially FILE_ATTRIBUTE_SYSTEM for custom folder icons)
const auto currentAttributes = GetFileAttributesW(reinterpret_cast<const wchar_t *>(path.utf16()));
if (currentAttributes != INVALID_FILE_ATTRIBUTES) {
    metadata.BasicInfo.FileAttributes = currentAttributes;
}

2. `createPlaceholderInfo()`

Modified to check for existing attributes before setting defaults:

const auto currentAttributes = GetFileAttributesW(reinterpret_cast<const wchar_t *>(path.utf16()));
if (currentAttributes != INVALID_FILE_ATTRIBUTES) {
    cloudEntry.FsMetadata.BasicInfo.FileAttributes = currentAttributes;
} else {
    cloudEntry.FsMetadata.BasicInfo.FileAttributes = fileInfo.isDir() ? FILE_ATTRIBUTE_DIRECTORY : FILE_ATTRIBUTE_NORMAL;
}

3. `updatePlaceholderState()`

Applied the same fix to the batch placeholder creation function.

Challenges I Faced

This contribution came with some significant challenges:

Building the project locally was difficult. Nextcloud Desktop has complex dependencies including Qt6 and KDE libraries. Setting up the build environment on Windows proved challenging.
Understanding the CFAPI. The Windows Cloud Files API was completely new to me, and I had to spend time reading Microsoft documentation to understand how it works.
Navigating a large C++ codebase. With hundreds of files and complex abstractions, finding the right place to make changes took patience and careful code tracing.

Current Status

I have completed the fix and verified that the code changes are correct based on my analysis of the codebase. The changes are ready for a pull request:

Files Changed:

src/libsync/vfs/cfapi/cfapiwrapper.cpp

Issue Reference:

https://github.com/nextcloud/desktop/issues/9197

What I Learned

This week taught me several valuable lessons:

How Windows file attributes work at a low level, especially FILE_ATTRIBUTE_SYSTEM
How the Cloud Files API (CFAPI) integrates with sync engines
How to navigate and understand a large unfamiliar C++ codebase
The importance of preserving system state during operations that modify files

Looking Ahead

My next steps are:

Submit a clean pull request with proper documentation
Respond to any code review feedback from maintainers
Work toward getting the fix merged

Conclusion

Week 2 pushed me into unfamiliar territory with C++ and Windows system programming. While it was challenging, I gained a much deeper understanding of how desktop sync applications work under the hood. Combined with my OpenCTI contribution from Week 1, I feel like I'm making meaningful progress in my open-source journey.

In my final blog post, I'll share the results of both contributions and reflect on what I've learned throughout Release 0.4.

Release 0.4: Contributing a New Feature to OpenCTI - A Cyber Threat Intelligence Platform

Hitesh Sachdeva — Fri, 12 Dec 2025 02:00:45 +0000

Finding My Way to OpenCTI

When I started planning what I wanted to work on for Release 0.4, I knew I wanted something that would challenge me and align with my interests. I had already contributed a small UI fix to OpenCTI, but this time I wanted to understand its implementation in depth.

OpenCTI stands for Open Cyber Threat Intelligence. It is an open-source platform that helps organizations collect, store, and analyze cyber-threat information. It serves as a central hub where teams gather intelligence about attackers, malware, vulnerabilities, and more to protect their systems.

What drew me to this project was both the subject matter and the technology stack. OpenCTI uses JavaScript and GraphQL on the backend—technologies I'm familiar with and wanted to explore further.

Discovering the Issue

While browsing issues in the OpenCTI repository, I found Issue #13594:

https://github.com/OpenCTI-Platform/opencti/issues/13594

The issue described a limitation with the export feature. When users exported data (like reports, indicators, or other threat intelligence), the process had a hardcoded 20-minute timeout. For large datasets, this was not enough, causing exports to fail. And administrators couldn't change the timeout without editing the source code.

The request was simple: make the export timeout configurable through platform settings.

Why This Issue Appealed to Me

I chose this issue because:

It was a feature request, not just a small fix.
It solved a real problem for users handling large datasets.
It had the right level of difficulty.
I wanted to understand how OpenCTI handles platform settings, caching, and GraphQL schema changes.

Understanding the Codebase

Before making changes, I explored how OpenCTI manages settings.

The GraphQL schema defines a Settings type where platform configurations live.
Settings are stored in the database and accessed through a caching layer.
The export logic is implemented in work.js, inside the workToExportFile function.

This is where the 20-minute timeout was hardcoded. Once I found that, the path forward became clear.

My Implementation Approach

My goal was to follow existing patterns and keep everything backward compatible.

Steps I Took:

Added a new field in the GraphQL schema:
- platform_export_timeout under Settings.
Modified the workToExportFile function to read the timeout from settings instead of using the hardcoded 20 minutes.
Implemented a fallback:
- If the setting is missing, the system still uses the default 20-minute timeout so older installations continue working normally.
Updated all places where workToExportFile is called, since the function now needed the context and became asynchronous.

Challenges Along the Way

The main challenges were:

Understanding the caching system (getEntityFromCache).
Following OpenCTI's conventions for schema changes and code formatting.
Ensuring backward compatibility.
Testing different scenarios: no setting, custom timeout, and long-running exports.

Submitting the Pull Request

After testing, I submitted Pull Request #13608:

https://github.com/OpenCTI-Platform/opencti/pull/13608

I documented the changes, explained the implementation clearly, and linked the PR to the original issue. I also confirmed everything required in the PR template.

What I Learned

Working on this feature taught me:

How GraphQL schema changes flow through a large application.
How platform-wide settings and caching are managed.
The importance of backward compatibility in open-source projects.
How to navigate and contribute effectively to a mature codebase.

Looking Ahead

My pull request is currently awaiting review. I'm checking for feedback and ready to make improvements if needed. I plan to continue contributing to open source and exploring more complex issues.

Conclusion

This was a meaningful learning experience that helped me understand both the technical and collaborative sides of open-source development. I look forward to sharing updates on the progress of this contribution in my next blog post.

When a Bug Isn't Actually a Bug: My Kestra Contribution Story

Hitesh Sachdeva — Sat, 06 Dec 2025 06:32:52 +0000

Overview

This week, I focused on a bug in Kestra, a workflow orchestration platform. Among my various open-source contributions, this one taught me an important lesson: sometimes what looks like a bug is actually a carefully considered design decision.

The Problem

I found an issue where the followExecution API endpoint was sending empty execution objects to users. When someone called this endpoint to track a workflow execution in real-time using Server-Sent Events (SSE), the first event they got looked like this:

// First event sent - almost empty
emitter.next(Event.of(Execution.builder()
    .id(executionId)
    .build()
).id("start"));

The object only had an ID with no actual execution data. This confused people using the SDK because they'd receive this empty object and wonder what went wrong. The issue also mentioned that if someone sent an invalid execution ID, they'd still get this fake object instead of a proper error.

My Solution

I spent time working on a fix that seemed straightforward: validate the execution exists first, then send complete data. My approach was to use an Await.until() method to wait up to 10 seconds for the execution to exist in the database:

// My approach - validate first
Execution execution = Await.until(
    () -> executionRepository.findById(tenantService.resolveTenant(), executionId).orElse(null),
    Duration.ofMillis(500),
    Duration.ofSeconds(10)
);

// Send complete execution data
emitter.next(Event.of(execution).id("start"));

I also added proper error handling that would return 404 errors for invalid execution IDs, and wrote unit tests to validate the behavior. Everything worked - the first event now contained real data instead of an empty shell.

Why It Got Rejected

The maintainer reviewed my PR and explained it didn't actually solve the problem. I was confused at first because my code clearly sent complete data. Then he pointed me to an earlier discussion where another maintainer had explained a critical constraint I missed.

The empty object was intentional. It exists to prevent resource leaks.

Here's the issue: Server-Sent Events work by keeping a connection open between server and client. If someone closes their browser tab before receiving any data, the server doesn't know the client disconnected. The connection just hangs there indefinitely, wasting memory and resources. These "phantom" connections can pile up and cause serious problems.

The solution was to send something - anything - immediately when the connection opens. This way, the server establishes the connection properly and can detect when clients disconnect. Even though it's just an empty object with an ID, it serves this important technical purpose.

Understanding the Trade-off

This was a classic engineering trade-off:

Option A: Send empty data immediately

Prevents resource leaks
Server can detect disconnections
Confuses API users

Option B: Wait and send complete data

Better developer experience
Clear, complete information
Risk of phantom connections and memory leaks

For a workflow orchestration platform that might handle thousands of concurrent executions, preventing resource leaks was more important than having perfect API responses. The team chose stability over convenience.

What Happened Next

After internal discussion, the team decided to close the issue. The empty object behavior would stay, and they'd just document this quirk in the SDK so developers would understand why the first event is incomplete.

My PR was closed without being merged, but the maintainer took time to explain why. He could have just rejected it immediately, but instead he helped me understand the architectural reasoning.

What I Actually Learned

About Server-Sent Events:

I learned how SSE connections work and why connection lifecycle management matters. The immediate response pattern prevents resource leaks - something I hadn't considered when I first read the issue.

About Trade-offs:

Not every problem has a perfect solution. Sometimes you choose the "less bad" option. In this case:

System stability vs perfect API responses
Resource management vs user confusion
Code fixes vs documentation

The team chose stability because Kestra needs to handle production workloads reliably.

About Reading Code:

When I saw "fake empty object" in the issue description, I assumed it was obviously wrong and jumped straight to fixing it. I should have asked myself: why was it implemented this way in the first place? There's usually a reason.

About Communication:

I asked the maintainer to clarify what I was missing, and he explained the internal discussion and decision. Sometimes issues get closed not because your code is bad, but because the team decides the current behavior is actually acceptable given the constraints.

Key Takeaways

Not all "bugs" are actually bugs. Sometimes weird behavior exists for good technical reasons. Ask why before assuming something is wrong.

Trade-offs are everywhere. Perfect solutions rarely exist. Teams make choices based on priorities - in this case, system stability over API convenience.

Closed PRs still teach you things. I learned about SSE, resource management, and architectural trade-offs even though nothing merged.

Context matters. Maintainers understand the bigger picture - system requirements, production constraints, past problems. They might reject your fix because they know something you don't.

Moving Forward

This experience changed how I approach issues:

Read the existing implementation carefully and ask why it works that way
Look for comments explaining unusual patterns
Ask about constraints before proposing solutions
Understand that maintainers aren't being difficult - they're protecting the system

Not every contribution makes it to production, but every attempt teaches you something about real-world software development.

Fixing Canvas Export Flicker in Kaoto: My Open Source Journey

Hitesh Sachdeva — Sat, 06 Dec 2025 06:18:55 +0000

The Problem

When users clicked "Export as image," the entire canvas would visibly jump around, center itself, and snap back. This happened because the export function manipulated the visible canvas Issue #2750:

// Old approach - caused flicker
const graph = controller.getGraph();
graph.reset();  // User sees this happening!
graph.fit(80);  // Canvas jumps around
graph.layout(); // Everything moves
await exportToPng(surface);

Users could see all these transformations happening in real-time before the export. Not a great experience.

My First Solution (That Got Rejected)

I submitted my Pull Request #2766 with a DOM cloning approach:

// Clone the visible canvas
const clone = visibleContainer.cloneNode(true) as HTMLElement;
clone.style.position = 'fixed';
clone.style.top = '-99999px';

// Transform and export the clone
await toPng(clone);

The flicker was gone! But the maintainer @lordrip explained this wasn't the right architectural approach. He wanted me to create a separate React component with its own controller that renders off-screen.

I was confused. Why rebuild everything when cloning worked?

Understanding the Real Solution

After reading Canvas.tsx, I understood the pattern. The canvas uses PatternFly's React Topology library with a controller:

const controller = useMemo(() => ControllerService.createController(), []);

The insight: create a second controller that renders invisibly. Transform that one, not the visible canvas!

Building the Hidden Canvas

I created HiddenCanvas.tsx that builds its own model from entities (same way the main Canvas does):

export const HiddenCanvas: FunctionComponent = (props) => {
  const hiddenController = useMemo(() => 
    ControllerService.createController(), 
    []
  );

  // Build model from entities
  const nodes: CanvasNode[] = [];
  const edges: CanvasEdge[] = [];

  props.entities.forEach((entity) => {
    const { nodes: childNodes, edges: childEdges } = 
      FlowService.getFlowDiagram(entity.id, entity.toVizNode());
    nodes.push(...childNodes);
    edges.push(...childEdges);
  });

Problems I Hit

TypeScript Errors: I tried copying nodes from the existing controller using toModel(), but this broke parent-child relationships. The fix was building a fresh model from entities using FlowService.getFlowDiagram().

Blank Exports: The SVG had no width/height attributes. I had to set them manually:

const bbox = svg.getBBox();
const padding = 10;
svg.setAttribute('width', String(bbox.width + padding * 2));
svg.setAttribute('height', String(bbox.height + padding * 2));

MobX Warnings: Graph transformations needed to be wrapped in action():

action(() => {
  hiddenGraph.reset();
  hiddenGraph.fit(10);
  hiddenGraph.layout();
})();

Timing Issues: I had to wait for the layout to complete before exporting. Instead of a blind timeout, I checked if nodes were actually positioned.

What I Learned

The maintainer was right. DOM cloning was a hack. Creating a proper component:

Is more maintainable
Follows React patterns
Works better with the library's architecture
Teaches you how the system actually works

Technical skills gained:

React context providers and controllers
MobX state management
SVG manipulation
Async timing with Promises
TypeScript type system

Results and What I Actually Learned

The final implementation completely eliminates the flicker. The visible canvas stays in place while the export happens in the background using the hidden controller. Users can now export their diagrams without any visual disruption.

But looking back, I understand why the maintainer pushed for the proper solution. DOM cloning might work, but it doesn't teach you anything about how the system actually works. By building a proper React component with its own controller, I learned:

How React's context and provider pattern works in complex applications
Why separating concerns matters (visible canvas vs export canvas)
How to build models from data sources instead of copying existing instances
The importance of understanding the library's architecture before writing code

The biggest lesson was that in open-source, it's not just about making something work - it's about making it work the right way so other developers can understand and maintain it later. The maintainer could have accepted my quick fix, but he took the time to explain why a better approach existed. That's what made this a real learning experience instead of just a bug fix.

Releasing share-my-repo: A Journey from Local Code to PyPI

Hitesh Sachdeva — Sat, 22 Nov 2025 04:15:36 +0000

Introduction

Over the past few weeks, I worked on share-my-repo, a CLI tool designed to package Git repositories into a format suitable for analysis by Large Language Models (LLMs). The goal was to create a user-friendly, configurable tool that could extract repository metadata, and generate structured file outputs.

Once the tool was ready, the next step was to release it so that others could easily install and use it via a package registry. This post walks through my entire release process, the challenges I faced, lessons learned, and the results of user testing.

Choosing a Release Tool and Package Registry

I decided to use Python’s standard packaging tools along with PyPI as the package registry. Specifically:

Build & Packaging: setuptools + wheel + setuptools_scm
Distribution/Upload: twine
Registry: PyPI (Python Package Index)

These tools are standard in the Python ecosystem and widely used for publishing Python packages.

Creating a Release

The release process involved several steps:

Updating Version

I updated the pyproject.toml to bump the version from 1.0.0 to 1.2.0.

Building the Package

I created a source distribution and a wheel using:

python -m build

This Produced:

dist/share_my_repo-1.2.0.tar.gz
dist/share_my_repo-1.2.0-py3-none-any.whl

Uploading to PyPI

I uploaded the distributions using twine:

python -m twine upload dist/*

Tagging the Release in GitHub

After pushing my code, I created a Git tag for the release:

git tag v1.2.0
git push origin main --tags

This made the release visible on GitHub under Releases.

Lessons Learned

pyproject.toml is powerful: Switching from setup.py to pyproject.toml made the build process cleaner and more modern.
User testing highlights documentation gaps: Even small missing instructions in README.md caused confusion for first-time users.
One "aha!" moment was realizing that setuptools_scm can auto-generate version numbers from Git tags, which makes managing releases much easier in the long run.

Changes Required for Package Format

To release share-my-repo successfully, I had to:

Move from a setup.py file to a pyproject.toml configuration.
Organize source code under a src folder to comply with best practices.
Add [project.scripts] entries in pyproject.toml for CLI functionality.
Ensure dependencies were correctly listed under [project.dependencies] and [project.optional-dependencies].

These changes were mostly structural and did not require altering the core functionality of the tool.

User Testing

I conducted a user testing session with a fellow classmate. Key observations:

They were able to install the package from PyPI without any issues.
Confusion arose when using optional flags like --preview and --use-gitignore because the README did not clearly explain the default behavior.
After observing them, I updated the README to include examples with common flag combinations.

This session was invaluable because it allowed me to fix documentation issues before sharing the package widely.

Installation & Usage

After release, users can install the package directly from PyPI release:

Install via PyPI

pip install share-my-repo

Install from Github

If you want to install the package directly from GitHub:

Clone the repository:

For End Users

Clone and install the package:

# clone the repository 
git clone https://github.com/yourusername/share-my-repo.git
cd share-my-repo

# install dependencies
pip install .

For Development / Contributors

Install in editable mode to make code changes without reinstalling:

# clone the repository 
git clone https://github.com/yourusername/share-my-repo.git
cd share-my-repo

# install dependencies
pip install -e .

Usage

share-my-repo [OPTIONS] [PATHS...]

Some Examples

Process the current directory and print Markdown to console:

share-my-repo .

Process a repository and save output to a file:

share-my-repo . --output repo_context.md

Include only Python and JavaScript files:

share-my-repo . --include "*.py,*.js"

Output as JSON:

share-my-repo . --format json --output repo.json

Conclusion

Releasing share-my-repo taught me key lessons:

Versioning is crucial: Always increment versions to avoid PyPI upload errors.
Modern packaging works: pyproject.toml makes builds cleaner and easier to manage.
Clear documentation matters: User testing revealed gaps and helped improve the README.
Automation helps: setuptools_scm simplifies version management.
User perspective is important: Observing real users showed how to make CLI options more intuitive.

Overall, this experience improved my understanding of Python packaging, release workflows, and creating user-friendly documentation.

Setting Up CI, Automated Testing, and Linting for My share-my-repo Project

Hitesh Sachdeva — Fri, 14 Nov 2025 15:07:28 +0000

This week's lab focused on managing project complexity using Continuous Integration (CI), automated testing, reproducible environments, and code quality tools. I applied these concepts to my own project, share-my-repo, and also collaborated on a partner's C++ project, Repository-Context-manager. Through the process, I learned not just how CI works, but also how it improves collaboration, reliability, and development workflow.

Setting Up GitHub Actions CI in My Python Project

To ensure my project always stays in a working state, I added a GitHub Actions CI workflow. The goal was simple: whenever someone pushes or opens a pull request, the code should automatically:

Install the environment
Run linting
Run all tests
Show test coverage

I created a .github/workflows/ci.yml file that:

Triggers on every push or PR to main
Sets up Python 3.11
Installs pytest, pytest-cov, flake8, and black
Runs linters before tests
Generates a coverage report on the terminal

This gave me a fully automated pipeline. I could visibly see CI results on every pull request, which made the entire development process more professional and error-free. Watching GitHub Actions run the workflow and report results felt like working on a real production project.

Testing CI Using My Own Pull Request

To verify that CI was truly working, I followed the workflow:

Created a new branch — add-more-tests.
Wrote additional unit tests for modules that had low coverage.
Pushed the branch and opened a pull request against main.
Observed GitHub Actions immediately fire up and begin running all steps.

I intentionally broke one of my functions to see how CI would behave. As expected, the tests failed and the pull request turned red. This highlighted how powerful CI is: no broken code can ever reach the main branch.

After fixing the bug, pushing again, and seeing CI pass, I gained confidence in using automated testing as a safeguard. This cycle of fail → inspect → fix → pass felt very satisfying and realistic.

Collaborating and Adding Tests to a Partner's C++ Project

My partner's project was completely different from mine — a C++ repository using Catch2 for testing. At first, I struggled to understand the README, so I reached out to the maintainer on Teams. After they clarified the instructions, I was able to set everything up and start working on the test.

Their workflow felt more complex than my Python setup because it required:

Compiling test files manually
Understanding multi-file C++ structures
Running tests with Catch2
Using a CI pipeline built around g++

Even though it was challenging, contributing to a project in a different language taught me a lot. I learned to slow down, carefully read unfamiliar code, and adapt to a new build system. Once I wrote my test case and opened the pull request, their CI passed successfully. PR

Overall, it felt like collaborating on a real open-source project, and it helped me understand how cross-language teamwork works in practice.

Adding Linting + Formatting: flake8 and black

As an optional enhancement, I integrated flake8 and black into my project. These tools help maintain code quality by:

flake8 → catching unused variables, undefined names, and style problems
black → automatically formatting the code to a consistent style

I added both tools to the dev dependencies in setup.py and updated my CI workflow to run them before tests. This created a nice structure:

flake8 checks for actual errors
black --check ensures formatting consistency
pytest runs only if both linters pass

This improved the readability of my project and prevented small bugs that often go unnoticed. It also taught me that CI is not just about testing — it's about enforcing standards across the whole team.

What I Learned About Continuous Integration

After setting up everything, working with two repositories, and experimenting with failures, I now have a solid understanding of CI's importance:

CI acts like a 24/7 automated reviewer, catching issues instantly.
It removes the risk of forgetting to run tests locally.
It provides detailed logs that make debugging very transparent.
It enforces consistency in both functionality and style.
It helps maintain a healthy main branch that always works.

Overall, CI transformed my project into something more professional and maintainable. It made the testing workflow feel more natural, especially when working with branches and pull requests.

Final Reflection

This lab tied together all the concepts from earlier weeks: testing, automation, collaboration, and reproducibility. By setting up CI, adding new tests, linting my code, and contributing to a partner's project, I gained hands-on experience with real software engineering workflows.

CI is no longer just a concept; I've now seen how developers rely on it every day to protect their projects from mistakes. It made me more confident in working with branching strategies, GitHub Actions, and cross-language testing environments.

How I Added Testing to share-my-repo Project and Learned a Lot

Hitesh Sachdeva — Thu, 06 Nov 2025 22:23:24 +0000

Testing is an important part of building software, but many developers, including me, sometimes skip it. In this post, I want to share how I added tests to my Python project, the tools I used, how I set them up, and what I learned along the way.

Tools I Chose for Testing

For my project, I decided to use pytest as my main testing framework and pytest-cov for code coverage because they are widely used, easy to set up, and provide clear feedback on test results and coverage.

pytest: pytest is a popular Python testing framework. It’s easy to use, supports simple tests, and has many features like fixtures and parameterized tests.
pytest-cov: This plugin works with pytest to show which parts of your code are covered by tests. It helps you find which lines are being missed.

I also used pytest-watch (ptw) to automatically run tests whenever I make changes. This makes development faster and helps catch problems immediately.

Setting Up Testing in My Project

Install dependencies:

   pip install pytest pytest-cov pytest-watch

Project Organization

I kept the source code in src/ and tests in tests/. Each file in the source has a corresponding test file, e.g., file_processor.py has tests/test_file_processor.py.

Writing Tests

I created test classes and methods for each function. For example:

class TestNormalizePath:
    def setup_method(self):
        self.processor = FileProcessor()

    def test_normalize_path_basic(self):
        path = Path("C:\\Users\\Example\\File.TXT")
        result = self.processor._normalize_path(path)
        assert result == "c:/users/example/file.txt"

Running Tests

pytest -v  # run all tests
pytest -v tests/test_file_processor.py  # run a single test file
pytest -v tests/test_file_processor.py::TestNormalizePath::test_normalize_path_basic  # run a single test
ptw  # watch for changes and run tests automatically

Check Code Coverage

pytest --cov=src/

I also made scripts (scripts/test.sh for Linux/macOS and scripts/test.bat for Windows) so anyone can run tests and see coverage easily.

What I Learned

Think like a pessimist: Writing tests made me consider all edge cases, like empty inputs or file errors.
Found hidden bugs: I found paths that didn’t normalize correctly on Windows and cases where the code failed if a file was outside the root directory.
Small tests are better: Writing focused tests per function made debugging much easier.

My Takeaways

Before this project, I rarely wrote automated tests. I mostly ran scripts and checked results manually. Now, I see that:

Tests prevent bugs when adding new features.
Coverage reports show what needs more testing.
Tests make the project easier for others to contribute to.

I plan to write tests for all my future Python projects. Adding code coverage and watch mode has improved my workflow and code quality a lot.

Wrapping Up Hacktoberfest 2025

Hitesh Sachdeva — Sat, 01 Nov 2025 03:01:47 +0000

Introduction

October has been an amazing month! This was my first time participating in Hacktoberfest, and the experience has been both exciting and educational. Over the past month, I contributed to multiple open-source projects, explored how large codebases are maintained, learned the processes behind Pull Requests (PRs), and gained confidence in making my work accepted by project maintainers.

Hacktoberfest taught me how open-source communities collaborate, how projects are structured, and the standards and measures maintainers follow to keep code clean and stable. Most importantly, it reinforced that contributing to open source isn’t just about coding, it’s about learning, communication, and teamwork.

My Contributions

NESY-Engine

Issue: #61 Pull Request: #68

I started small with NESY-Engine by improving the documentation of the HUD class. I added class summaries, detailed constructor explanations, property descriptions, and usage examples. This made it easier for developers to understand and use the HUD class.

Starting with a documentation task taught me the value of beginning small, building confidence, and understanding project structure before attempting more complex contributions. It also showed me the importance of clear, structured documentation for open-source projects.

OpenCTI

Issue: #12824 Pull Request: #12967

This was a small UI fix. The Playbook update drawer was incorrectly displaying "Update a decay rule" instead of "Update a playbook". I corrected the title in PlaybookEdition.tsx, ensuring it followed the proper i18n translation structure.

This contribution showed me that even small fixes matter, especially for user clarity, and taught me the importance of paying attention to UI details and consistency in a large project.

Kestra

Issue: #12090 Pull Request: #12148

In Kestra, the Pebble chunk filter was throwing type-casting exceptions when integers were used instead of Longs. I updated the filter to handle any Number type, added runtime checks, and wrote unit tests to confirm proper behavior.

This was a more challenging fix that taught me about Java type-casting, workflow logic, and the importance of writing robust unit tests. Successfully getting this PR merged boosted my confidence immensely.

Kaoto

Issue: #2637 Pull Request: #2669

I fixed drag-and-drop issues in nested workflow nodes by correcting component logic and testing different container setups. Though smaller in scope, this fix improved user experience significantly.

Contributing to Kaoto taught me that even minor UI improvements matter and that understanding the tool you work on makes contributions easier and more meaningful.

Reflections and Learnings

Looking back over October:

I contributed to four projects and had all my PRs merged, which was incredibly satisfying.
I learned how open-source projects are maintained, including testing standards, code reviews, and collaboration practices.
My confidence in reading complex codebases, debugging issues, and making contributions accepted has grown tremendously.
I realized that communication, asking questions, and submitting thoughtful PRs are just as important as writing code.
Contributing to projects I actually use (like Kaoto) or widely-used platforms (like Kestra and OpenCTI) made the experience more rewarding.

Hacktoberfest showed me that open source is not just about contributing code,it’s about learning, exploring, and growing as a developer. I plan to continue contributing to open source in the future, and this first Hacktoberfest has motivated me to take on bigger and more complex projects.

Hacktoberfest Week 4 – Improving DataMapper Logic in Kaoto

Hitesh Sachdeva — Fri, 31 Oct 2025 15:57:57 +0000

As Hacktoberfest comes to an end, I decided to take on one more interesting challenge, this time in the Kaoto project. Kaoto is an open-source low-code integration platform that allows users to visually design and configure integrations. It’s built on top of Apache Camel, which makes it powerful but also quite complex.

After spending my previous week working on a core backend issue in Kestra, I wanted to dive deeper into something that touched core logic and UI behavior at the same time. I chose to work on a drag-and-drop (DnD) bug in Kaoto’s DataMapper UI, a component that lets users visually map data sources to targets.

The Issue

The problem Issue #2637 was that users could drag and drop a primitive source Body (without a schema) and create a mapping. This looked fine in the UI, but it actually caused runtime failures because the backend engine (camel-xslt-saxon) expected the body to be an XML Document, not a primitive type.

So in short, users could make an invalid mapping that would always fail later. My goal was to prevent this from happening at the UI level.

My Approach

At first, I tried to fix the issue by checking for primitive types and blocking the mapping when users tried to drop it. However, the project maintainer suggested a cleaner and more reliable approach — disable the drag-and-drop action altogether for primitive source bodies.

This was a great learning moment. Instead of fixing the problem after it happens, it’s better to prevent it from happening in the first place, a core principle of good UX and system design.

So, I updated the NodeContainer.tsx component to skip attaching the DnDContainer for primitive source body nodes. This ensured that users simply could not drag them at all, while still allowing parameters (even primitive ones) to be draggable and valid.

The Fix

The final fix included PR:

Disabling drag-and-drop for primitive source Body nodes.
Keeping Parameters draggable even if they’re primitive.
Refactoring the code to use a more readable flag (hasDnD instead of noDnD) for clarity.
Testing all drag-and-drop actions to ensure no regressions or console errors.

Once I submitted the PR, the maintainers reviewed it quickly. After a few small suggestions (like simplifying logic and improving flag naming), the changes were approved and merged.

Challenges & Learnings

This contribution felt different from my earlier ones. It wasn’t just about fixing a bug, it was about understanding core UI logic and improving how users interact with the system.

Here’s what I learned:

How drag-and-drop logic is implemented in React-based UIs.
Why preventing invalid user actions early leads to better software design.
How to interpret and implement maintainer feedback effectively.

Reflection

This last week of Hacktoberfest has been a great wrap-up. I started the month working on documentation in HUD, then explored backend issues in large systems like Kestra, and finally ended it by improving UI logic in Kaoto — connecting both worlds.

Every PR taught me something new. The whole experience reminded me that open-source is not just about writing code, it’s about learning, collaborating, and growing as a developer.

Hacktoberfest 2025 has definitely been a crazy but rewarding experience. I’m excited to continue contributing to open source beyond October and keep pushing myself toward more challenging issues in the future.

Understanding the Gitignore Feature in Repomix: A Technical Deep Dive

Hitesh Sachdeva — Wed, 29 Oct 2025 04:36:10 +0000

Repomix is a powerful tool designed to search and filter files in a repository, packaging them for AI consumption. One key feature that stood out during my code exploration is its handling of .gitignore files. In this blog post, I’ll explain how this feature works, how the code is structured, what I learned, and my strategy for understanding it.

What the Feature Does

The Gitignore feature allows Repomix to ignore files and directories that are listed in .gitignore or other ignore files. This ensures that temporary, build, or dependency files (like node_modules, test files, or log files) are not included in the search results or final package.

In short, this feature ensures that only relevant files are processed, which is critical for performance and accuracy.

How the Feature Works

The implementation is primarily found in src/core/file/fileSearch.ts. The process can be summarized in these steps:

1. Load Ignore Patterns from Git

Repomix gathers patterns from multiple sources, including .git/info/exclude when useGitignore is enabled in the config file :

if (config.ignore.useGitignore) {
  const excludeFilePath = path.join(rootDir, '.git', 'info', 'exclude');
  const excludeFileContent = await fs.readFile(excludeFilePath, 'utf8');
  const excludePatterns = parseIgnoreContent(excludeFileContent);
  for (const pattern of excludePatterns) ignorePatterns.add(pattern);
}

.git/info/exclude: Contains local ignore rules for the repository.
config.ignore.useGitignore: A flag in the Repomix configuration to enable .gitignore support.
Patterns are parsed line by line, ignoring empty lines or comments (#)

export const parseIgnoreContent = (content: string): string[] => {
  if (!content) return [];
  return content.split('\n').reduce<string[]>((acc, line) => {
    const trimmedLine = line.trim();
    if (trimmedLine && !trimmedLine.startsWith('#')) {
      acc.push(trimmedLine);
    }
    return acc;
  }, []);
};

2. Respect `.gitignore` During File Search

Once ignore patterns are collected, Repomix uses globby to search files while excluding ignored ones:

const filePaths = await globby(includePatterns, {
  cwd: rootDir,
  ignore: [...adjustedIgnorePatterns],
  ignoreFiles: [...ignoreFilePatterns], // includes '**/.gitignore' if enabled
  onlyFiles: true,
  dot: true,
  followSymbolicLinks: false,
});

ignore: Contains all patterns, including .gitignore rules from .git/info/exclude.
ignoreFiles: Optionally tells globby to ignore the ignore files themselves (.gitignore or .repomixignore).

This ensures that .gitignore rules are actively applied, and unwanted files are not included in the results.

3. Handle Git Worktrees

For repositories using Git worktrees, .git is a file reference rather than a directory. Repomix adjusts the ignore patterns accordingly:

const gitPath = path.join(rootDir, '.git');
const isWorktree = await isGitWorktreeRef(gitPath);

if (isWorktree) {
  const gitIndex = adjustedIgnorePatterns.indexOf('.git/**');
  if (gitIndex !== -1) {
    adjustedIgnorePatterns.splice(gitIndex, 1);
    adjustedIgnorePatterns.push('.git'); // ignore the reference file
  }
}

This prevents .git reference files from being mistakenly included in the search.

Code Organization

The .gitignore feature in Repomix is implemented in a modular and organized way:

fileSearch.ts → Contains the main logic for searching files and directories while respecting ignore rules.
defaultIgnore.js → Provides default ignore patterns like node_modules/**.
errorHandle.ts → Defines custom errors such as RepomixError and PermissionError.
permissionCheck.ts → Checks read/write permissions for directories.
Helper functions
- parseIgnoreContent → Reads .git/info/exclude and converts it into usable ignore patterns.
- escapeGlobPattern → Escapes special characters in paths to prevent glob errors.
- isGitWorktreeRef → Detects if .git is a Git worktree reference file.

This separation makes it easy to extend or modify behavior, such as adding new ignore patterns or supporting additional ignore files.

Things I Learned

Reading this code taught me several important lessons:

Practical use of glob patterns – Using globby with ignore patterns allows Repomix to filter files effectively, respecting .git/info/exclude, optional .gitignore, and other custom rules.
Error handling strategy – File operations are wrapped in try/catch blocks and errors are re-thrown as custom error classes, which is cleaner than letting Node.js errors propagate.
Git-specific handling – Git worktrees change how .git appears (as a reference file instead of a directory). Repomix handles this gracefully to avoid false positives.
Combining multiple ignore sources – .git/info/exclude, optional .gitignore, default ignore patterns, custom patterns, and explicit output files are all merged carefully to ensure accurate file filtering.

Challenges & Unknowns

Initially, locating which folders need to be looked into for reading the code was difficult.

Some parts of the code were tricky:

Understanding Git worktree handling.
Figuring out how .git/info/exclude interacts with .gitignore patterns.
Behavior with nested .gitignore files isn’t fully clear since the code primarily reads .git/info/exclude.

Strategies for Reading the Code

Started with using git grep to find all references to .gitignore and globby.
Looked into the searchFiles function to understand the file search flow.
Traced helper functions like getIgnorePatterns, parseIgnoreContent, escapeGlobPattern, and isGitWorktreeRef.
Used AI (ChatGPT) to clarify tricky logic, especially around Git worktrees.
Checked the configuration interface RepomixConfigMerged to see how users can enable .gitignore support.

I think using git grep for locating the files that need to be read and then ChatGPT for understanding the code worked for me.

Conclusion

Repomix’s .gitignore support is a reliable and efficient file filtering system. It combines .git/info/exclude, optional .gitignore, default patterns, and custom rules, while handling Git worktrees correctly. This ensures only relevant files are included, making it a strong example of Git-aware file handling in Node.js.

Adding .gitignore Support to share-my-repo: A New Feature to Streamline Repository Analysis

Hitesh Sachdeva — Wed, 29 Oct 2025 04:35:37 +0000

Introduction

This feature was inspired by Repomix, a repository analysis tool that allows users to examine their codebases with various built-in features, including file exclusion based on .gitignore files. Repomix demonstrated how powerful this feature could be in streamlining repository analysis, and I wanted to bring similar functionality to share-my-repo. By supporting .gitignore, users of share-my-repo can now avoid unnecessary files from their analysis, just as Repomix does.

What Is the `.gitignore` Support Feature?

The .gitignore support in share-my-repo is designed to automatically skip files that are ignored by Git during repository analysis. When processing a repository, share-my-repo will now check for the .gitignore file and exclude any files or directories listed there from being included in the output. This is particularly useful when working with large repositories that contain irrelevant or non-code files that don't need to be analyzed.

How It Works

Detecting .gitignore: The tool checks for .gitignore files at the root and any subdirectories of the repository.
Reading the Patterns: It reads the patterns inside .gitignore and matches them against the files and directories in the repository to exclude them from the analysis.
Excluding Ignored Files: Files and directories that match the .gitignore patterns are automatically excluded from the output, ensuring that the repository analysis focuses only on relevant code files.

What Problem Does It Solve?

When analyzing large repositories, developers often face the issue of unnecessary files (such as log files, build artifacts, or temporary files) cluttering the analysis output. By supporting .gitignore, this feature ensures that only relevant files are processed, making repository analysis faster, more focused, and more efficient. It saves developers time and allows them to focus on what truly matters, the code. issue-10

What I Did Similarly to Repomix

The main aspect I took from Repomix was respecting .gitignore rules automatically.

Previously, my tool would process all files in a repository, including files that are meant to be ignored. Now, it follows a two-step approach:

Detect Ignored Files First: The script reads .gitignore in the repository root (and optionally in subdirectories) and parses the patterns.
Filter Files: During file discovery, any files matching the .gitignore patterns are automatically excluded before further processing.

This is similar to how Repomix avoids processing ignored files to keep the dataset clean and relevant.

What I Did Differently

The main difference lies in the flexibility and integration with other features. Repomix automatically respects .gitignore but does not provide additional user-level configuration.

In share-my-repo:

Users can still provide include/exclude patterns on top of .gitignore rules.
.gitignore support is integrated with TOML configuration, so users can enable or disable it by default.
The filtering works alongside other features like file previews, line numbers, and file size limits, which Repomix does not provide in the same context.

Next Steps for the Feature

While the .gitignore support feature is functional, there are still some areas where it can be improved and expanded. Here are the next steps:

Support for Multiple .gitignore Files: Currently, the tool only checks the .gitignore file in the root directory. Adding support for multiple .gitignore files in subdirectories will further improve the tool's flexibility. Support multiple .gitignore files
CLI Flag to Toggle .gitignore Support: Adding a flag to enable or disable .gitignore processing from the command line would give users more control over their analysis. Add CLI toggle for .gitignore
Error Handling Improvements: Ensuring that the tool handles malformed .gitignore files gracefully will make the tool more robust.Handle malformed .gitignore files gracefully

Forem: Hitesh Sachdeva

Release 0.4 Final: Reflecting on My Open Source Contributions for release 0.4

Overview

Contribution 1: OpenCTI - Configurable Export Timeout

The Problem

My Solution

Technical Highlights

Result

Contribution 2: Nextcloud Desktop - Folder Icon Fix

The Problem

Root Cause

My Solution

Result

Skills I Developed

Technical Skills

Soft Skills

Challenges and How I Overcame Them

Challenge 1: Complex Build Environments

Challenge 2: Understanding New APIs

Challenge 3: Following Project Conventions

Key Takeaways

What I Would Do Differently

Conclusion

Links

# Release 0.4 Week 2: Fixing a Windows Bug in Nextcloud Desktop Client

Moving to a New Challenge

The Bug I Found

Understanding the Root Cause

My Fix

1. updatePlaceholderState()

2. createPlaceholderInfo()

3. updatePlaceholderState()

Challenges I Faced

Current Status

What I Learned

Looking Ahead

Conclusion

Release 0.4: Contributing a New Feature to OpenCTI - A Cyber Threat Intelligence Platform

Finding My Way to OpenCTI

Discovering the Issue

Why This Issue Appealed to Me

Understanding the Codebase

My Implementation Approach

Steps I Took:

Challenges Along the Way

Submitting the Pull Request

What I Learned

Looking Ahead

Conclusion

When a Bug Isn't Actually a Bug: My Kestra Contribution Story

Overview

The Problem

My Solution

Why It Got Rejected

Understanding the Trade-off

What Happened Next

What I Actually Learned

Key Takeaways

Moving Forward

Fixing Canvas Export Flicker in Kaoto: My Open Source Journey

The Problem

My First Solution (That Got Rejected)

Understanding the Real Solution

Building the Hidden Canvas

Problems I Hit

What I Learned

Results and What I Actually Learned

Releasing share-my-repo: A Journey from Local Code to PyPI

Introduction

Choosing a Release Tool and Package Registry

Creating a Release

Updating Version

Building the Package

Uploading to PyPI

Tagging the Release in GitHub

Lessons Learned

Changes Required for Package Format

User Testing

Installation & Usage

Install via PyPI

1. `updatePlaceholderState()`

2. `createPlaceholderInfo()`

3. `updatePlaceholderState()`

2. Respect `.gitignore` During File Search

What Is the `.gitignore` Support Feature?