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

Update GitLab API call investigation

Browse source 
After today discussion with @t0xic0der I updated the GitLab API investigation
with feedback from him.

Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2023-01-24 14:45:11 +01:00
parent e0799069a7
commit 45e9d9bf2e
1 changed files with 45 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

50
docs/pagure2gitlab/gitlab.rst
View file

@ -71,14 +71,54 @@ I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/5
}
This creates `comment <https://gitlab.com/testgroup519/arc/-/issues/1#note_1245817484>`_ on
the previously created issue. In this case the comment was created by user, who executed the
API call and according to API documentation it's not possible to change it.
the previously created issue. In this case the comment was created by user, who API key is used
to execute API call and according to API documentation it's not possible to change it.
We can overcome this by adding relevant information to each comment or issue. For example
the payload can look like this:
.. code-block:: json
{
"created_at": "2023-01-19T12:59:59Z",
"body": "(This comment was added by [t0xic0der](https://accounts.fedoraproject.org/user/t0xic0der/))\n\nHere's a sample comment as you requested @zlopez."
}
Importing pull requests
-----------------------
To import the pull requests it's possible to use `Create MR API call
<https://docs.gitlab.com/ee/api/merge_requests.html#create-mr>`_. However this doesn't allow
us to open pull requests from any repository that is not hosted on GitLab. Following are
the options that could be leveraged by the user for migration:
1. Don't import any pull requests
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
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
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
local branches, which allows us to easily create a pull request. I don't recommend using
this approach as it needs plenty of adjustments on the migrated repository before the actual
migration.
In addition to the issue mentioned above the pull requests will have the same issue with author
as import of tickets. The author will be set to whoever generated the API key.
Conclusion
----------
Using the REST API v4 is not useful for our purpose, because it will set author of every pull
request, issue and comment to user running the migration tool. This means that we will lose
most of the information we want to preserve. Thus it doesn't make sense to continue in the
investigation.
request, issue and comment to user running the migration tool. This could be mitigated by
adding the information directly to the pull request, issue or comment with link to FAS account
of the user.