GitLab FUSE blueprint

Why is this change being made?

This MR proposes a new architecture blueprint for GitLab FUSE, a filesystem-based solution for lightweight access to Git repositories and CI/CD artifacts. The blueprint addresses inefficiencies in current workflows where:

• Sparse repository access requires full Git clones (60-900 seconds, 100MB-1GB+ downloads) even when only accessing <5% of files
• Container-based CI/CD lacks efficient ways to mount repositories and artifacts as read-write filesystems without full copying
• Development tooling (LLM code review, static analysis, documentation generation) needs fast, targeted file access without Git's bulk transfer model

The proposed solution provides:

• FUSE-based filesystem with lazy loading from GitLab APIs (15-300x faster for sparse access)
• Copy-on-write layer implemented in FUSE for read-write mounts without mutating shared cache
• Artifact support with on-demand extraction from job archives

This blueprint prioritizes portability (pure FUSE implementation, no kernel overlay dependency) for diverse CI/CD environments while maintaining performance (network latency dominates FUSE overhead).

The design enables new use cases like instant repository mounting for AI-powered code review and container builds with shared read-only cache but independent writable state.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Add GitLab FUSE architecture blueprint with artifact and CoW support

---