I don't believe this is feasible—at least not for Git repositories. While build artifacts, container images, and LFS objects can be stored on an S3 backend, compatibility with the iRODS S3 API would need to be thoroughly tested.
Currently, NFS is still supported as a backend for build artifacts and similar data (excluding Git repository data). However, GitLab is actively moving away from NFS. For example, the next-generation container registry in GitLab will only support Object Storage.
We do have some projects that use GitLab CI/CD pipelines to store build artifacts along with metadata into iRODS. However, this is a different use case than using iRODS as a backend for GitLab itself.
Additionally, it's unclear what the added value would be in storing GitLab data on iRODS. GitLab uses opaque 64-character hexadecimal identifiers for its data objects, rendering the data unusable without access to the GitLab database.
References:
-
Using NFS with GitLab | GitLab Docs-
Object storage | GitLab Docs