[GH-ISSUE #22909] feat: Native Azure DevOps Repos (Git) integration as a Knowledge Base source for RAG #19840

New Issue

GiteaMirror · 2026-04-20T02:20:52-05:00

GiteaMirror commented

2026-04-20 02:20:52 -05:00

Originally created by @giovanisp on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22909

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

In enterprise and team environments, source code lives in Azure DevOps Git repositories. Currently there is no native way to point a Knowledge Base directly at an Azure DevOps Repo and have OpenWebUI sync and index the content automatically for RAG.
The only workaround is maintaining an external sync script that periodically clones the repo, uploads files via POST /api/v1/files/, adds them to a KB via POST /api/v1/knowledge/{id}/file/add, and manually tracks additions/deletions using file hashes. This is fragile, requires infrastructure outside OpenWebUI, and creates a significant operational burden for admins — especially when the goal is simply to give a whole team a shared AI assistant that knows the codebase, with zero per-user configuration.

Desired Solution you'd like

A first-class "Git Repository" Knowledge Base source type, with Azure DevOps Repos as a supported provider, configurable entirely from the Admin UI:

Connection settings: organization URL, project, repository name, branch, and authentication (PAT or Azure AD service principal)
Indexing filter: file extensions or path patterns to include (e.g. *.cs, *.ts, src/**)
Sync trigger: either a scheduled interval (every N minutes) or an inbound webhook endpoint that Azure DevOps can call on push events for incremental re-sync
Zero user-side config: once an admin attaches the KB to a Custom Model, all users of that model get RAG on the codebase automatically

The Git repo source would appear alongside existing KB sources (manual file upload, web crawl) in Workspace → Knowledge.

Alternatives Considered

External sync script via REST API: functional but brittle. Requires a separate scheduled process, manual file_id state tracking, and constant maintenance whenever the OpenWebUI API evolves.
Manual file upload: completely impractical for active codebases with daily commits and multiple contributors.
Generic Git clone (non Azure-specific): a plain git clone-based integration would already cover the majority of use cases; Azure DevOps-specific auth could be layered on top as a provider option. OpenTerminal also does not work fine.

Additional Context

This pattern is already established in other RAG frameworks (LlamaIndex Git loader, LangChain GitLoader, etc.) and is one of the most requested enterprise use cases for self-hosted AI assistants.
Azure DevOps is dominant in corporate environments — exactly where OpenWebUI is self-hosted and where teams need a shared model that understands the codebase without each user managing their own document uploads.
The underlying "Git repo as KB source" abstraction naturally extends to GitHub, GitLab, and Bitbucket, so the implementation would benefit a much wider portion of the community beyond Azure DevOps users alone.
For large repositories, incremental sync based on commit diff (only re-embed changed files) would be essential to avoid re-processing the entire codebase on every push.

Originally created by @giovanisp on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22909 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description In enterprise and team environments, source code lives in Azure DevOps Git repositories. Currently there is no native way to point a Knowledge Base directly at an Azure DevOps Repo and have OpenWebUI sync and index the content automatically for RAG. The only workaround is maintaining an external sync script that periodically clones the repo, uploads files via POST /api/v1/files/, adds them to a KB via POST /api/v1/knowledge/{id}/file/add, and manually tracks additions/deletions using file hashes. This is fragile, requires infrastructure outside OpenWebUI, and creates a significant operational burden for admins — especially when the goal is simply to give a whole team a shared AI assistant that knows the codebase, with zero per-user configuration. ### Desired Solution you'd like A first-class "Git Repository" Knowledge Base source type, with Azure DevOps Repos as a supported provider, configurable entirely from the Admin UI: Connection settings: organization URL, project, repository name, branch, and authentication (PAT or Azure AD service principal) Indexing filter: file extensions or path patterns to include (e.g. *.cs, *.ts, src/**) Sync trigger: either a scheduled interval (every N minutes) or an inbound webhook endpoint that Azure DevOps can call on push events for incremental re-sync Zero user-side config: once an admin attaches the KB to a Custom Model, all users of that model get RAG on the codebase automatically The Git repo source would appear alongside existing KB sources (manual file upload, web crawl) in Workspace → Knowledge. ### Alternatives Considered - External sync script via REST API: functional but brittle. Requires a separate scheduled process, manual file_id state tracking, and constant maintenance whenever the OpenWebUI API evolves. - Manual file upload: completely impractical for active codebases with daily commits and multiple contributors. - Generic Git clone (non Azure-specific): a plain git clone-based integration would already cover the majority of use cases; Azure DevOps-specific auth could be layered on top as a provider option. OpenTerminal also does not work fine. ### Additional Context - This pattern is already established in other RAG frameworks (LlamaIndex Git loader, LangChain GitLoader, etc.) and is one of the most requested enterprise use cases for self-hosted AI assistants. - Azure DevOps is dominant in corporate environments — exactly where OpenWebUI is self-hosted and where teams need a shared model that understands the codebase without each user managing their own document uploads. - The underlying "Git repo as KB source" abstraction naturally extends to GitHub, GitLab, and Bitbucket, so the implementation would benefit a much wider portion of the community beyond Azure DevOps users alone. - For large repositories, incremental sync based on commit diff (only re-embed changed files) would be essential to avoid re-processing the entire codebase on every push.

GiteaMirror closed this issue

2026-04-20 02:20:53 -05:00

GiteaMirror commented

2026-04-20 02:20:54 -05:00

@selenecodes commented on GitHub (Mar 24, 2026):

Would be nice if this were implemented as a generic adapter so that it would be easy to implement other sources as well e.g. SMB shares/local files, chat integration with things like Slack.

@selenecodes commented on GitHub (Mar 24, 2026): Would be nice if this were implemented as a generic adapter so that it would be easy to implement other sources as well e.g. SMB shares/local files, chat integration with things like Slack.

GiteaMirror commented

2026-04-20 02:20:55 -05:00

@Classic298 commented on GitHub (Apr 15, 2026):

Interesting feature request, definitely useful, but belongs in discussions as per

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

@Classic298 commented on GitHub (Apr 15, 2026): Interesting feature request, definitely useful, but belongs in discussions as per > I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.