Infrastructure/arc
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Add conclusions to Pagure2Gitlab investigation

Browse source 
This adds conclusion to the investigation and updates few things in GitLab API
investigation that are related to that.

Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2023-01-25 15:26:23 +01:00 • committed by zlopez
parent 1552736e56
commit f99f7e1d56
2 changed files with 45 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/pagure2gitlab/gitlab.rst
View file

@ -84,6 +84,18 @@ I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/5
"body": "(This comment was added by [t0xic0der](https://accounts.fedoraproject.org/user/t0xic0der/))\n\nHere's a sample comment as you requested @zlopez."
}
The information about GitLab account could be added as well. This could be obtained by using
`users API call <https://docs.gitlab.com/ee/api/users.html>`_ with `mail` as parameter. If the
user is found it will username of the user on GitLab. The final requests could look like this:
.. code-block:: json
{
"created_at": "2023-01-19T12:59:59Z",
"body": "(This comment was added by @t0xic0der [FAS](https://accounts.fedoraproject.org/user/t0xic0der/))\n\nHere's a sample comment as you requested @zlopez."
}
Importing pull requests
-----------------------
@ -98,13 +110,18 @@ the options that could be leveraged by the user for migration:
This option makes the migration process much easier, but we will not have any already
existing pull request in GitLab at all.
2. Migrate forks to GitLab as well
2. Merge all the pull requests before migration
This is the best option for migration. Migration of the merged code is easy and there wouldn't
be any information loss when migrating.
3. Migrate forks to GitLab as well
This will allow us to create pull requests from migrated forks of the original repository.
But this option means migrating plenty of git repositories, just to open the pull requests.
If this option is chosen, I'm recommending to only limit this to open pull requests on Pagure.
3. Create branches on migrated repository
4. Create branches on migrated repository
It's easy to open pull request from branch on the same repository, but this will mean that
tool will need to go through all the forks, add them as remotes and then add those as

32
docs/pagure2gitlab/index.rst
View file

@ -21,9 +21,9 @@ Requirements
* Self-service tool
* Git commit history preservation
* Ability to migrate pagure issues
* Ability to migrate pull-requests
* Command line interface
* Ability to migrate files uploaded to PRs and issues
* Ability to migrate pull-requests
* Mapping of Fedora identity to GitLab users
* Tool should be usable by both CentOS and Fedora users
* Ability to access the correct namespace on GitLab
@ -33,6 +33,7 @@ Nice to have
List of features that would be nice to have.
* Graphical UI
* Web interface
* Syncing the FAS usernames to GitLab as users migrate for already migrated projects
@ -53,16 +54,35 @@ Following are the investigations of Pagure options to export and GitLab options
Conclusions
-----------
Conclusion for this initiative...
Creating the tool for migration is possible, but with a few caveats.
We don't recommend to migrate pull requests
(:ref:`pagure2gitlab/gitlab:Importing pull requests`).
We didn't investigate the possibility of providing web interface, it's definitely possible,
but it will add much to complexity of the tool and we need to host it and deploy as well.
The main issue with the migration is that all the comments, issues are created by the user
that owns the API token, which is made to execute the API calls. This issue is explained
in :ref:`pagure2gitlab/gitlab:Importing ticker` with possible proposed solution.
The user that is using the tool will need to have permissions to create new repositories in
the GitLab group, to which the repository will be migrated.
Proposed Roadmap
----------------
* Step 1 - Investigate Pagure2GitLab
* Step 2 - ???
* Step 3 - Profit!
1. Create the tool for migration using GitLab API
2. (Optional) Create a bot user for migration and share the API key with trusted people. This
will help to migrate some of the projects as neutral user instead of the user, who is using
the tool.
3. Prepare the documentation for migration process.
4. Announce the migration tool is available.
Estimate of work
----------------
Estimation of work for this initiative...
This work will need 2 developers.
The estimation for this project is 3 weeks.