📏 Convention: Should we keep Gitea provider support alongside GitLab?

Date: 2026-02-10
Time: 17:02:35 UTC
Session: gspace1-102.11
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Should we keep Gitea provider support alongside GitLab?

Task: Remove Gitea provider - Session 102.3

🎯 Decision Made

Chosen:

Removed Gitea from git-provider module. GitLab is the only provider. Changed from factory pattern (switch on GIT_PROVIDER env) to useExisting: GitLabProviderService. The gitea-provider.service.ts file remains as dead code but is no longer instantiated — eliminates the GITEA_API_TOKEN warning in production logs.

Options Considered:

1. Keep factory pattern with both providers
2. Remove Gitea entirely and simplify to useExisting

💭 Reasoning

Gitea was the original git provider but was replaced by GitLab in Session 49.5. The factory pattern kept both providers instantiated even though only GitLab was used, causing a noisy warning in every backend-api deployment. Services use the GIT_PROVIDER_SERVICE injection token (not GiteaProviderService directly), so removal is safe. useExisting is simpler than the factory pattern when there's only one implementation.

📁 Files Involved

• apis/backend-api/src/app/git-provider/git-provider.module.ts
• apis/backend-api/src/app/git-provider/index.ts

🔗 Related

• Decision ID: dev_1770742955402_k4ek8zk
• Session: 102
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation