Pagure Exporter is now available in the Fedora package repositories and PyPI. The Pagure Exporter tool enables the migration of a Pagure repository (including metadata and issues) to a GitLab repository. Install pagure-exporter from Fedora Linux repositories or PyPI to get started.
With most of the projects used in the Fedora Project community moving away from Pagure to the Fedora Project’s namespace on GitLab.com, Justin W. Flory proposed an initiative to the Community Platform Engineering team. The objective was to investigate and develop a self-service tool capable of helping contributors to the community migrate their project assets from Pagure to GitLab as reliably as possible, similar to the pagure-importer tool from Trac in 2015.
After investigation and development of a prototype by ARC investigators, Michal Konecny and Akashdeep Dhar as well as a backlog refinement process, the project was scoped for implementation as a part of the Fedora Infrastructure and Release Engineering work for Q4 2023 by the team’s then-product owner, Aoife Moloney.
After around a month and a half of designing, developing and testing by Akashdeep Dhar, the Pagure Exporter tool is now published for use in Fedora Linux repositories and PyPI.
Install Pagure Exporter on Fedora Linux
A package is available in the official Fedora repositories. As of publishing time, the package is available on Fedora Linux 38, 39, and Rawhide.
sudo dnf install pagure-exporterInstall Pagure Exporter from PyPI
A package is available as a PyPI project. This can be used from any distribution:
pip install pagure-exporterFuture plans for Pagure Exporter
While the application has a set of known issues, it has the following set of features today, which will expand as the development progresses:
- Transferring repository files from Pagure projects to GitLab
- Filtering repository transfer operation by branch names
- Transferring issue tickets from Pagure projects to GitLab
- Filtering issue ticket transfer operation by statuses and identities
- Migrating states, comments, and tags/labels for issues
- Inbuilt logging library is used for better compatibility with journaling
Apart from the features mentioned above, the following things encourage community members to participate in the project’s development:
- Excellent overall codebase quality is ensured with 100% coverage of functional code
- Over 75 checks are provided for unit-based and integration-based codebase testing
- GitHub Actions and Pre-Commit CI are enabled to automate maintaining code quality
- Documentation related to usage, development and testing are provided
Get involved with Pagure Exporter
In case you encounter any issues or have a suggestion to make the project better, please let us know on the Pagure Exporter issue tracker. To contribute, please make your pull requests on GitHub.
Thank you for the good news. I wish we had the tool when we were moving: Copr's migration to GitHub
Wait - “are we GitLab.com yet”? You make it sound as if we had decided on a forge already. That question is still open. I know that one is about dist-git primarily, but that may determine where you want your project to be hosted.
Still open is also the question what “allow Fedora to manage your gitlab.com account” means when you want to join our namespace on GitLab.com with an existing account.
The exporter is good for exporting to any GitLab instance, isn’ it?
What are you even talking about and where is the basis of this statement coming from?
As you can see there are plenty of projects already on fedora · GitLab. It is probably unfortunate to say most of the projects, but plenty of project already using it.
We didn’t decided on git forge yet, but there was request for this tool already. No project is kept from moving to Fedora GitLab if they want.
The tool should be able to use with any GitLab instance, but it was tested only on GitLab.com
It is important not to confuse dist-git with “forges where teams and SIGs do their work and planning.” The availability of this tool does not bear any weight on dist-git.
But given the large breadth of teams that are working on fedora · GitLab already, this shouldn’t be too surprising that a tool is created to enable further migration.
This article is not about policy.
Why the switch to GitLab?