<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=232982) </details> <!--IssueSummary end--> ### Problem statement When https://gitlab.com/gitlab-org/gitlab/-/issues/235770 is complete & Gitea and Github importers will share the same `Gitlab::GithubImport::ParallelImporter` (after https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37934 is merged) due to Gitea being (mostly) Github API compatible (with few minor differences). https://gitlab.com/gitlab-org/gitlab/blob/georgekoltsov/gitea-parallel-importer/lib/gitlab/import_sources.rb#L14 This allows faster change that affects both Importers but can cause unexpected problems when individual importer needs to be tweaked without changing behaviour in other. ### Proposed solution For this reason, split up Gitea and Github to have separate importers. A lot of Github Importer's code can still be reused, without introducing duplication. Github Import process is composed of a set of workers and importers that are going to be ran in a specific sequence. E.g. - Import base repo - Import labels, milestones - Import MRs, issues https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/github_import/parallel_importer.rb#L7-7 Add similar to Github importer for Gitea, reusing representation, importer classes but having a separate Importing flow, to allow alternations to the import process, given each individual vendor limitation (for example, Gitea Importer does not import diff notes on MRs, and currently the importer class execution is skipped with a conditional, which is not ideal https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37934/diffs#bf481ddda29c01f4c31858bba048460cb759ca5b)