This is one of the Code walkthrough I wrote while exploring the Gitea codebase.
A Gitea instance can be dumped and restored as a whole with a SQL dump of the database and a copy of all the files (lfs, avatars, etc.). The web interface provides a way to permanently migrate a project from other forges (GitHub, GitLab, etc.).
The /api/v1/repos/migrate API endpoint does the same by calling the MigrateRepository function. There are a few unit tests and integration tests.
To migrate from, for instance, GitLab to Gitea, GitlabDownloaderFactory is registered to create a GitlabDownloader which implements the Downloader base interface common to all migrations (the compatibility is enforced at compile time). As an example, issues are downloaded from GitLab using the go-gitlab package and stored in memory by the migrateRepository function. This in-memory representation is then saved in Gitea using an object that implements the Uploader base interface.
It is also possible to dump a single project and restore it with the gitea CLI, on the machine hosting the Gitea instance.
The implementation of the dump-repo relies on the DumpRepository method. It borrows from the logic of the migrations available from the web interface:
dump-repowill download from Gitea and upload them to files (i.e. save them to disk).restore-repowill download from files (i.e. load them from disk) and upload them in batch to avoid memory exhaustion.
When the project is restored, all entries (issues, etc.) are authored by the user doing the migration. The user of the forge from which the project was migrated is preserved: the updateMigrationPosterIDByGitService function records the name and numerical id for issues, pull requests, milestones, … in the OriginalAuthor and OriginalAuthorId fields.