### Summary Currently, we allow 100 includes and each `include` triggers a Gitaly call. Our docs recommend not going over 30 Gitaly calls per request: https://docs.gitlab.com/ee/development/gitaly.html#toomanyinvocationserror-errors ### Proposal These requests to Gitaly should be batched Useful data here: https://gitlab.com/groups/gitlab-org/-/epics/7290#note_1168994718 <- Internal only ### Implementation | Work Type | Description | Issue link | | ------ | ------ | ------ | | | **NOTE:** :rotating_light: All below issues can be done in parallel | | | ~backend | Backend: The gitlab-ci.yml is limited to 100 includes | https://gitlab.com/gitlab-org/gitlab/-/issues/207270 | | ~backend |Backend: Remove N+1 for Gitaly requests when fetching `includes`|https://gitlab.com/gitlab-org/gitlab/-/issues/344829 | | ~backend ~frontend | Improve the error messaging when fetching remote includes are timing out | https://gitlab.com/gitlab-org/gitlab/-/issues/351168 | | ~backend | Backend: Improve CI Linter performance through parallelizing HTTP calls | https://gitlab.com/gitlab-org/gitlab/-/issues/351250 | | ~backend | Backend: Caching includes to improve performance when using remote includes | https://gitlab.com/gitlab-org/gitlab/-/issues/351252 | | ~backend | **Backend: Batch request calls to Gitaly when fetching `include`** | :point_left: You are here | | ~backend | Backend: Group files by projects in config_file_project_validate_access | https://gitlab.com/gitlab-org/gitlab/-/issues/382751 |