Spike: GitLab Integration

[asaphko]

We currently have a stable and highly used GitHub integration. We're hearing from existing and potential customers that they would also like to connect their GitLab repositories with Flagsmith.

This issue is a Spike, with the following expected outcomes:

1. Review the existing GitHub integration code - I've been told it's old and messy - and assess if and which refactoring is needed to bring it up-to-date.
2. Consider a modular approach to the above - we now want to add support for GitLab, but will probably want to add support for additional services in the future, such as BitBucket.
3. Plan and estimate the required work for the above + adding support for GitLab to match our existing GitHub integration functionality and capabilities.
4. Plan and estimate the required work for adding GitLab support for our newly released GitHub Code References feature.

The goal is to provide a same level of service, capabilities, and features for users who use GitLab instead of GitHub.

We can also approach this the other way around: instead of first refactoring GitHub, and then adding GitLab, we should consider building GitLab from scratch using new code, and later migrating the existing GitHub integration to use the new modular approach.

And another option - build the new integration based on our existing code, and consider refactoring only when and if value is proven. This is the fastest path to value, and a conscious decision to accumulate some technical debt for future cleanup.

[emyller]

This is written with the keyboard.

Foreword

The direction this spike goes is affected by a PoC attempted by Asaph: #7028

This PoC makes a copy of the current GitHub integration, assuming that's the quickest path to validate a similar set of features to GitLab.

Originally, the issue proposed two other alternatives:

• Refactor the GitHub integration before introducing GitLab's.
• Introduce a good-looking GitLab integration now, migrate GitHub later.

Only the first option above would lead us through a potentially tech-debt-free path. However, the second option, as well as the alternative taken by the PoC, ultimately leads to even more tech debt around this integration. A good amount of it.

PoC-influenced Scope

Please read my review to the PoC pull request.

Symbiotic Approach

Also suggested as next step, after experimenting on private code.

I'd really like to spend some time taking a human look at the existing architecture. Ultimately, I'd like to see one that wraps both issues/PRs and Code References integrations together — they were built separately, consciously, as we decided to only reuse the existing GitHub integration architecture when it was a viable option.

Rather than drifting even further away from a good code design, we could timebox drafting a redesign of the very foundation of integrating with VCS: we'll have the opportunity to build safer code, easier to maintain, and also, perhaps most importantly, we'd improve user experience and reduce integration friction, e.g. by unifying the authentication flow towards both issues/PRs and Code References integrations, or by introducing a webhook to collect code references organisation-wide instead of the current manual per-repo GHA workflow setup.

Once we have the architecture design, and a base foundation, we could strategise with Claude agents the cherry-picking from this PoC code — by then already validated if we accept the proposal above — into a new solid foundation, and coordinate bite-sized pull requests for our review, and easier familiarity-building.

This should maybe take a sprint?

---

I will invest my time further into this spike now, or later, depending on how we decide:

1. Focus on validating the PoC in a private space now, investigate a refactor, etc later.
2. Investigate a refactor now, start safe from OSS.
3. Something else?

[emyller]

Given the new efforts taken by @asaphko on opening new smaller PRs, which seem to address all #7028 review comments, I assume the issues/MRs side of the integration will be taken care of without needing new issues planned:

• feat(gitlab): add GitLab API v4 client with typed responses #7120
• feat(gitlab): add configuration persistence and resource browsing #7121
• feat(gitlab): add webhook handling, tagging, and shared VCS module #7122
• feat(gitlab): add frontend components for GitLab integration #7123

As for Code References, I've updated #7000 with information and a plan (sub-issues) to coordinate the efforts.