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

fix parsing errors and sphinx warnings

Browse source 
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
This commit is contained in:
Ryan Lercho 2023-11-16 08:02:56 +10:00 • committed by zlopez
parent 8fb9b2fdf0
commit ba720c3d77
98 changed files with 4799 additions and 4788 deletions
Download patch file Download diff file Expand all files Collapse all files

143
docs/pagure2gitlab/gitlab.rst
View file

@ -3,49 +3,50 @@
GitLab API investigation
========================
This document investigates API calls that are needed to address the requirements for Pagure to GitLab
importer. Currently the GitLab provides both `REST <https://docs.gitlab.com/ee/api/rest/>`_
and `GraphQL <https://docs.gitlab.com/ee/api/graphql/>`_ APIs. In this investigation I will only
focus on REST API v4, because GraphQL API doesn't provide required calls
(importing project and importing merge requests).
This document investigates API calls that are needed to address the requirements for
Pagure to GitLab importer. Currently the GitLab provides both `REST
<https://docs.gitlab.com/ee/api/rest/>`_ and `GraphQL
<https://docs.gitlab.com/ee/api/graphql/>`_ APIs. In this investigation I will only
focus on REST API v4, because GraphQL API doesn't provide required calls (importing
project and importing merge requests).
All the REST API calls need user to provide
`GitLab API token <https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html>`_.
All the REST API calls need user to provide `GitLab API token
<https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html>`_.
For the purpose of this investigation I tried to import `ARC repository
<https://pagure.io/fedora-infra/arc>`_ to GitLab.
GitLab API documentation: https://docs.gitlab.com/ee/api/
Importing a git repository
--------------------------
Project can be imported by using `create project call
<https://docs.gitlab.com/ee/api/projects.html#create-project>`_. Following is a payload for import
of the ARC repository.
<https://docs.gitlab.com/ee/api/projects.html#create-project>`_. Following is a payload
for import of the ARC repository.
.. code-block:: json
{
"name":"arc",
"description":"The Advance Reconnaissance Crew",
"namespace_id":"10910066",
"import_url":"https://pagure.io/fedora-infra/arc.git"
}
This creates `ARC repository on GitLab <https://gitlab.com/testgroup519/arc>`_ with the whole
commit history and users mapped by the e-mail.
{
"name":"arc",
"description":"The Advance Reconnaissance Crew",
"namespace_id":"10910066",
"import_url":"https://pagure.io/fedora-infra/arc.git"
}
This creates `ARC repository on GitLab <https://gitlab.com/testgroup519/arc>`_ with the
whole commit history and users mapped by the e-mail.
Importing ticket
----------------
Ticket can be imported by `creating an issue <https://docs.gitlab.com/ee/api/issues.html#new-issue>`_
, `commenting on it <https://docs.gitlab.com/ee/api/notes.html#create-new-issue-note>`_,
eventually close it by `editing the issue
<https://docs.gitlab.com/ee/api/notes.html#create-new-issue-note>`_ and add any attachments by
`uploading file to project <https://docs.gitlab.com/ee/api/projects.html#upload-a-file>`_.
Ticket can be imported by `creating an issue
<https://docs.gitlab.com/ee/api/issues.html#new-issue>`_ , `commenting on it
<https://docs.gitlab.com/ee/api/notes.html#create-new-issue-note>`_, eventually close it
by `editing the issue
<https://docs.gitlab.com/ee/api/notes.html#create-new-issue-note>`_ and add any
attachments by `uploading file to project
<https://docs.gitlab.com/ee/api/projects.html#upload-a-file>`_.
I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/59>`_.
@ -53,11 +54,11 @@ I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/5
.. code-block:: json
{
"created_at": "2023-01-19T11:41:40Z",
"title": "Investigate the GitLab API for Pagure to Gitlab importer",
"description": "Investigate the GitLab API for Pagure to Gitlab importer ARC investigation. This ticket will also work as a test ticket in investigation."
}
{
"created_at": "2023-01-19T11:41:40Z",
"title": "Investigate the GitLab API for Pagure to Gitlab importer",
"description": "Investigate the GitLab API for Pagure to Gitlab importer ARC investigation. This ticket will also work as a test ticket in investigation."
}
This creates the `issue on GitLab <https://gitlab.com/testgroup519/arc/-/issues/1>`_.
@ -65,45 +66,44 @@ I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/5
.. code-block:: json
{
"created_at": "2023-01-19T12:59:59Z",
"body": "Here's a sample comment as you requested @zlopez."
}
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 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:
{
"created_at": "2023-01-19T12:59:59Z",
"body": "Here's a sample comment as you requested @zlopez."
}
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 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."
}
{
"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."
}
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:
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."
}
{
"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
-----------------------
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:
<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
@ -112,30 +112,31 @@ the options that could be leveraged by the user for migration:
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.
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.
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.
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
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.
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.
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 could be mitigated by
adding the information directly to the pull request, issue or comment with link to FAS account
of the user.
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 could be
mitigated by adding the information directly to the pull request, issue or comment with
link to FAS account of the user.

210
docs/pagure2gitlab/gitlab_file_import.rst
View file

@ -4,141 +4,145 @@ GitLab import from a file
=========================
GitLab provides option to `import a new project from a file
<https://docs.gitlab.com/ee/api/project_import_export.html>`_. This option is created for migrating
projects from one GitLab instance to another. In case of Pagure to GitLab importer we need to adapt
Pagure data to file format used by GitLab. This document will investigate that option.
<https://docs.gitlab.com/ee/api/project_import_export.html>`_. This option is created
for migrating projects from one GitLab instance to another. In case of Pagure to GitLab
importer we need to adapt Pagure data to file format used by GitLab. This document will
investigate that option.
GitLab file format
------------------
For purpose of investigation of the GitLab export format I tried to export `test project
<https://gitlab.com/testgroup519/arc>`_ I created during the investigation of GitLab API.
See :doc:`gitlab`.
<https://gitlab.com/testgroup519/arc>`_ I created during the investigation of GitLab
API. See :doc:`gitlab`.
The export will generate one archive in `tar.gz` format. This archive contains a following
directory structure::
The export will generate one archive in `tar.gz` format. This archive contains a
following directory structure:
2023-01-20_11-48-813_testgroup519_arc_export
├── GITLAB_REVISION
├── GITLAB_VERSION
├── lfs-objects
│ └── 45a5d77993d525cdda15d08e63c34339a1bf49a43756a05908082bb04b4c4087
├── lfs-objects.json
├── project.bundle
├── project.design.bundle
├── snippets
├── tree
│ ├── project
│ │ ├── auto_devops.ndjson
│ │ ├── boards.ndjson
│ │ ├── ci_cd_settings.ndjson
│ │ ├── ci_pipelines.ndjson
│ │ ├── container_expiration_policy.ndjson
│ │ ├── custom_attributes.ndjson
│ │ ├── error_tracking_setting.ndjson
│ │ ├── external_pull_requests.ndjson
│ │ ├── issues.ndjson
│ │ ├── labels.ndjson
│ │ ├── merge_requests.ndjson
│ │ ├── metrics_setting.ndjson
│ │ ├── milestones.ndjson
│ │ ├── pipeline_schedules.ndjson
│ │ ├── project_badges.ndjson
│ │ ├── project_feature.ndjson
│ │ ├── project_members.ndjson
│ │ ├── prometheus_metrics.ndjson
│ │ ├── protected_branches.ndjson
│ │ ├── protected_environments.ndjson
│ │ ├── protected_tags.ndjson
│ │ ├── push_rule.ndjson
│ │ ├── releases.ndjson
│ │ ├── security_setting.ndjson
│ │ ├── service_desk_setting.ndjson
│ │ └── snippets.ndjson
│ └── project.json
├── uploads
│ └── 8b4f7247f154d0b77c5d7d13e16cb904
│ └── Infra___Releng_2022.jpg
└── VERSION
.. code-block::
7 directories, 35 files
2023-01-20_11-48-813_testgroup519_arc_export
├── GITLAB_REVISION
├── GITLAB_VERSION
├── lfs-objects
│ └── 45a5d77993d525cdda15d08e63c34339a1bf49a43756a05908082bb04b4c4087
├── lfs-objects.json
├── project.bundle
├── project.design.bundle
├── snippets
├── tree
│ ├── project
│ │ ├── auto_devops.ndjson
│ │ ├── boards.ndjson
│ │ ├── ci_cd_settings.ndjson
│ │ ├── ci_pipelines.ndjson
│ │ ├── container_expiration_policy.ndjson
│ │ ├── custom_attributes.ndjson
│ │ ├── error_tracking_setting.ndjson
│ │ ├── external_pull_requests.ndjson
│ │ ├── issues.ndjson
│ │ ├── labels.ndjson
│ │ ├── merge_requests.ndjson
│ │ ├── metrics_setting.ndjson
│ │ ├── milestones.ndjson
│ │ ├── pipeline_schedules.ndjson
│ │ ├── project_badges.ndjson
│ │ ├── project_feature.ndjson
│ │ ├── project_members.ndjson
│ │ ├── prometheus_metrics.ndjson
│ │ ├── protected_branches.ndjson
│ │ ├── protected_environments.ndjson
│ │ ├── protected_tags.ndjson
│ │ ├── push_rule.ndjson
│ │ ├── releases.ndjson
│ │ ├── security_setting.ndjson
│ │ ├── service_desk_setting.ndjson
│ │ └── snippets.ndjson
│ └── project.json
├── uploads
│ └── 8b4f7247f154d0b77c5d7d13e16cb904
│ └── Infra___Releng_2022.jpg
└── VERSION
7 directories, 35 files
Following is the explanation of some of the files found in the archive:
* GitLab metadata files (version and revision)
* `.bundle` file which is created by `git bundle <https://git-scm.com/docs/git-bundle>`_ command.
You can easily look at the content of `.bundle` file by using `git clone` command.
* `.design.bundle` contains all the attachments from issues and merge requests. It is
a repository file bundled by `git bundle <https://git-scm.com/docs/git-bundle>`_ command.
* `lsf-object.json` contains list of hashes of designs and their mapping to issue id or merge
request id. This is something we can skip, because Pagure doesn't have this feature.
* `VERSION` file contains version, but I was not able what this version refers to. My assumption is
that it's version of the export tool.
* `lfs-objects/` folder contains all the designs named by hash. This is something we can skip,
because Pagure doesn't have this feature.
* `snippets/` folder contains `GitLab snippets <https://docs.gitlab.com/ee/user/snippets.html>`_.
* `tree/project.json` file contains all the project metadata in JSON format.
* `tree/project/` contains files in `ndjson format <http://ndjson.org/>`_ describing various
objects defined in GitLab project. For purpose of this investigation only `issues.ndjson` and
`merge_requests.ndjson` are important for us.
* `uploads/` folder contains all the attachments from issues or merge requests.
- GitLab metadata files (version and revision)
- `.bundle` file which is created by `git bundle <https://git-scm.com/docs/git-bundle>`_
command. You can easily look at the content of `.bundle` file by using `git clone`
command.
- `.design.bundle` contains all the attachments from issues and merge requests. It is a
repository file bundled by `git bundle <https://git-scm.com/docs/git-bundle>`_
command.
- `lsf-object.json` contains list of hashes of designs and their mapping to issue id or
merge request id. This is something we can skip, because Pagure doesn't have this
feature.
- `VERSION` file contains version, but I was not able what this version refers to. My
assumption is that it's version of the export tool.
- `lfs-objects/` folder contains all the designs named by hash. This is something we can
skip, because Pagure doesn't have this feature.
- `snippets/` folder contains `GitLab snippets
<https://docs.gitlab.com/ee/user/snippets.html>`_.
- `tree/project.json` file contains all the project metadata in JSON format.
- `tree/project/` contains files in `ndjson format <http://ndjson.org/>`_ describing
various objects defined in GitLab project. For purpose of this investigation only
`issues.ndjson` and `merge_requests.ndjson` are important for us.
- `uploads/` folder contains all the attachments from issues or merge requests.
Conversion of Pagure project to GitLab file formats
---------------------------------------------------
For purpose of the investigation I tried to convert `ARC project <https://pagure.io/fedora-infra/arc>`_
hosted on Pagure to GitLab import format. For this purpose I started with the export generated by GitLab
and changed files to correspond to what I want to import.
For purpose of the investigation I tried to convert `ARC project
<https://pagure.io/fedora-infra/arc>`_ hosted on Pagure to GitLab import format. For
this purpose I started with the export generated by GitLab and changed files to
correspond to what I want to import.
Here is the list of all files that I needed to prepare and their content with explanation:
Here is the list of all files that I needed to prepare and their content with
explanation:
* `project.bundle` is a binary bundle file created by `git bundle <https://git-scm.com/docs/git-bundle>`_
command. It was created by running `git bundle create project.bundle --all` inside ARC project repository.
* `tree/project/issues.ndjson` contains issues description in `ndjson format <http://ndjson.org/>`_.
The file contains `project_id` or `author_id` set to 0, instead it contains `author` object with
FAS username and public FAS e-mail. Unfortunately if the `author_id` isn't recognized by GitLab it
will create the issue or comment as a user who is providing the import, completely ignoring the author
- `project.bundle` is a binary bundle file created by `git bundle
<https://git-scm.com/docs/git-bundle>`_ command. It was created by running `git bundle
create project.bundle --all` inside ARC project repository.
- `tree/project/issues.ndjson` contains issues description in `ndjson format
<http://ndjson.org/>`_. The file contains `project_id` or `author_id` set to 0,
instead it contains `author` object with FAS username and public FAS e-mail.
Unfortunately if the `author_id` isn't recognized by GitLab it will create the issue
or comment as a user who is providing the import, completely ignoring the author
object in JSON.
.. code-block:: json
{"title":"Investigate the GitLab API for Pagure to Gitlab importer","author_id":0,"author":{"username": "zlopez","email": "michal.konecny@pacse.eu"},"project_id":42729361,"created_at":"2023-01-19T11:41:40.000Z","updated_at":"2023-01-19T14:06:47.659Z","description":"Investigate the GitLab API for Pagure to Gitlab importer ARC investigation. This ticket will also work as a test ticket in investigation.","iid":1,"updated_by_id":null,"weight":null,"confidential":false,"due_date":null,"lock_version":0,"time_estimate":0,"relative_position":513,"last_edited_at":null,"last_edited_by_id":null,"discussion_locked":null,"closed_at":"2023-01-19T14:06:47.641Z","closed_by_id":3072529,"health_status":null,"external_key":null,"issue_type":"issue","state":"closed","events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T13:07:11.164Z","updated_at":"2023-01-19T13:07:11.164Z","action":"created","target_type":"Issue","fingerprint":null},{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T14:06:47.712Z","updated_at":"2023-01-19T14:06:47.712Z","action":"closed","target_type":"Issue","fingerprint":null}],"timelogs":[],"notes":[{"note":"Here's a sample comment as you requested @zlopez.","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-19T12:59:59.000Z","updated_at":"2023-01-19T12:59:59.000Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":false,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"f98cdeabaaec68ae453e1dbf5d9e535fbbcede0a","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-19T12:59:59.000Z","author":{"name":"Zlopez"},"award_emoji":[],"events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T13:13:21.071Z","updated_at":"2023-01-19T13:13:21.071Z","action":"commented","target_type":"Note","fingerprint":null}]}],"label_links":[],"resource_label_events":[],"resource_milestone_events":[],"resource_state_events":[{"user_id":3072529,"created_at":"2023-01-19T14:06:47.734Z","state":"closed","source_commit":null,"close_after_error_tracking_resolve":false,"close_auto_resolve_prometheus_alert":false}],"designs":[],"design_versions":[],"issue_assignees":[],"zoom_meetings":[],"award_emoji":[],"resource_iteration_events":[]}
{"title":"Test open issue","author_id":0,"author":{"username": "akashdeep","email": "akashdeep.dhar@gmail.com"},"project_id":42729361,"created_at":"2023-01-19T14:07:05.823Z","updated_at":"2023-01-20T11:48:02.495Z","description":"Test open issue","iid":2,"updated_by_id":null,"weight":null,"confidential":false,"due_date":null,"lock_version":0,"time_estimate":0,"relative_position":1026,"last_edited_at":null,"last_edited_by_id":null,"discussion_locked":null,"closed_at":null,"closed_by_id":null,"health_status":null,"external_key":null,"issue_type":"issue","state":"opened","events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T14:07:05.930Z","updated_at":"2023-01-19T14:07:05.930Z","action":"created","target_type":"Issue","fingerprint":null}],"timelogs":[],"notes":[{"note":"![Infra___Releng_2022](/uploads/8b4f7247f154d0b77c5d7d13e16cb904/Infra___Releng_2022.jpg)","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-20T11:48:02.435Z","updated_at":"2023-01-20T11:48:02.435Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":false,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"30302c7dee98663fcfca845a2ec2715eb3e35e4f","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-20T11:48:02.435Z","author":{"name":"Zlopez"},"award_emoji":[],"events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-20T11:48:02.617Z","updated_at":"2023-01-20T11:48:02.617Z","action":"commented","target_type":"Note","fingerprint":null}]},{"note":"added [1 design](/testgroup519/arc/-/issues/2/designs?version=490993)","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-19T14:07:45.310Z","updated_at":"2023-01-19T14:07:45.315Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":true,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"e15e7c584cc7e6c7e298529f034f0b55eeacca90","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-19T14:07:45.315Z","author":{"name":"Zlopez"},"award_emoji":[],"system_note_metadata":{"commit_count":null,"action":"designs_added","created_at":"2023-01-19T14:07:45.343Z","updated_at":"2023-01-19T14:07:45.343Z"},"events":[]}],"label_links":[],"resource_label_events":[],"resource_milestone_events":[],"resource_state_events":[],"designs":[{"project_id":42729361,"filename":"Infra___Releng_2022.jpg","relative_position":null,"iid":1,"notes":[]}],"design_versions":[{"sha":"69419c215f53d401c1b3c451e6fc08e3351d2679","created_at":"2023-01-19T14:07:45.233Z","author_id":3072529,"actions":[{"event":"creation","design":{"project_id":42729361,"filename":"Infra___Releng_2022.jpg","relative_position":null,"iid":1}}]}],"issue_assignees":[],"zoom_meetings":[],"award_emoji":[],"resource_iteration_events":[]}
{"title":"Investigate the GitLab API for Pagure to Gitlab importer","author_id":0,"author":{"username": "zlopez","email": "michal.konecny@pacse.eu"},"project_id":42729361,"created_at":"2023-01-19T11:41:40.000Z","updated_at":"2023-01-19T14:06:47.659Z","description":"Investigate the GitLab API for Pagure to Gitlab importer ARC investigation. This ticket will also work as a test ticket in investigation.","iid":1,"updated_by_id":null,"weight":null,"confidential":false,"due_date":null,"lock_version":0,"time_estimate":0,"relative_position":513,"last_edited_at":null,"last_edited_by_id":null,"discussion_locked":null,"closed_at":"2023-01-19T14:06:47.641Z","closed_by_id":3072529,"health_status":null,"external_key":null,"issue_type":"issue","state":"closed","events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T13:07:11.164Z","updated_at":"2023-01-19T13:07:11.164Z","action":"created","target_type":"Issue","fingerprint":null},{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T14:06:47.712Z","updated_at":"2023-01-19T14:06:47.712Z","action":"closed","target_type":"Issue","fingerprint":null}],"timelogs":[],"notes":[{"note":"Here's a sample comment as you requested @zlopez.","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-19T12:59:59.000Z","updated_at":"2023-01-19T12:59:59.000Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":false,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"f98cdeabaaec68ae453e1dbf5d9e535fbbcede0a","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-19T12:59:59.000Z","author":{"name":"Zlopez"},"award_emoji":[],"events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T13:13:21.071Z","updated_at":"2023-01-19T13:13:21.071Z","action":"commented","target_type":"Note","fingerprint":null}]}],"label_links":[],"resource_label_events":[],"resource_milestone_events":[],"resource_state_events":[{"user_id":3072529,"created_at":"2023-01-19T14:06:47.734Z","state":"closed","source_commit":null,"close_after_error_tracking_resolve":false,"close_auto_resolve_prometheus_alert":false}],"designs":[],"design_versions":[],"issue_assignees":[],"zoom_meetings":[],"award_emoji":[],"resource_iteration_events":[]}
{"title":"Test open issue","author_id":0,"author":{"username": "akashdeep","email": "akashdeep.dhar@gmail.com"},"project_id":42729361,"created_at":"2023-01-19T14:07:05.823Z","updated_at":"2023-01-20T11:48:02.495Z","description":"Test open issue","iid":2,"updated_by_id":null,"weight":null,"confidential":false,"due_date":null,"lock_version":0,"time_estimate":0,"relative_position":1026,"last_edited_at":null,"last_edited_by_id":null,"discussion_locked":null,"closed_at":null,"closed_by_id":null,"health_status":null,"external_key":null,"issue_type":"issue","state":"opened","events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-19T14:07:05.930Z","updated_at":"2023-01-19T14:07:05.930Z","action":"created","target_type":"Issue","fingerprint":null}],"timelogs":[],"notes":[{"note":"![Infra___Releng_2022](/uploads/8b4f7247f154d0b77c5d7d13e16cb904/Infra___Releng_2022.jpg)","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-20T11:48:02.435Z","updated_at":"2023-01-20T11:48:02.435Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":false,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"30302c7dee98663fcfca845a2ec2715eb3e35e4f","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-20T11:48:02.435Z","author":{"name":"Zlopez"},"award_emoji":[],"events":[{"project_id":42729361,"author_id":3072529,"created_at":"2023-01-20T11:48:02.617Z","updated_at":"2023-01-20T11:48:02.617Z","action":"commented","target_type":"Note","fingerprint":null}]},{"note":"added [1 design](/testgroup519/arc/-/issues/2/designs?version=490993)","noteable_type":"Issue","author_id":3072529,"created_at":"2023-01-19T14:07:45.310Z","updated_at":"2023-01-19T14:07:45.315Z","project_id":42729361,"attachment":{"url":null},"line_code":null,"commit_id":null,"st_diff":null,"system":true,"updated_by_id":null,"type":null,"position":null,"original_position":null,"resolved_at":null,"resolved_by_id":null,"discussion_id":"e15e7c584cc7e6c7e298529f034f0b55eeacca90","change_position":null,"resolved_by_push":null,"confidential":null,"last_edited_at":"2023-01-19T14:07:45.315Z","author":{"name":"Zlopez"},"award_emoji":[],"system_note_metadata":{"commit_count":null,"action":"designs_added","created_at":"2023-01-19T14:07:45.343Z","updated_at":"2023-01-19T14:07:45.343Z"},"events":[]}],"label_links":[],"resource_label_events":[],"resource_milestone_events":[],"resource_state_events":[],"designs":[{"project_id":42729361,"filename":"Infra___Releng_2022.jpg","relative_position":null,"iid":1,"notes":[]}],"design_versions":[{"sha":"69419c215f53d401c1b3c451e6fc08e3351d2679","created_at":"2023-01-19T14:07:45.233Z","author_id":3072529,"actions":[{"event":"creation","design":{"project_id":42729361,"filename":"Infra___Releng_2022.jpg","relative_position":null,"iid":1}}]}],"issue_assignees":[],"zoom_meetings":[],"award_emoji":[],"resource_iteration_events":[]}
Importing the archive to GitLab
-------------------------------
Archive for the migration is prepared by executing `tar -czvf test_arc_export.tar.gz .` command. This needs
to be executed in the root folder of the prepared file structure, otherwise the import will fail with
`No such file or directory`.
Archive for the migration is prepared by executing `tar -czvf test_arc_export.tar.gz .`
command. This needs to be executed in the root folder of the prepared file structure,
otherwise the import will fail with `No such file or directory`.
To import the archive to GitLab `API call <https://docs.gitlab.com/ee/api/project_import_export.html#import-a-file>`_
could be used. Here is the full API call made by `curl`::
To import the archive to GitLab `API call
<https://docs.gitlab.com/ee/api/project_import_export.html#import-a-file>`_ could be
used. Here is the full API call made by `curl`:
curl --request POST --header "PRIVATE-TOKEN: XXX" --form "namespace=testgroup519" --form "path=arc2" --form "file=@test_arc_export.tar.gz" "https://gitlab.com/api/v4/projects/import"
.. code-block::
curl --request POST --header "PRIVATE-TOKEN: XXX" --form "namespace=testgroup519" --form "path=arc2" --form "file=@test_arc_export.tar.gz" "https://gitlab.com/api/v4/projects/import"
To check for any error in the import use GitLab `import status API call
<https://docs.gitlab.com/ee/api/project_import_export.html#import-status>`_. This could be made by `curl`::
<https://docs.gitlab.com/ee/api/project_import_export.html#import-status>`_. This could
be made by `curl`:
curl --header "PRIVATE-TOKEN: XXX" "https://gitlab.com/api/v4/projects/<id_returned_by_import_call>/import"
.. code-block::
curl --header "PRIVATE-TOKEN: XXX" "https://gitlab.com/api/v4/projects/<id_returned_by_import_call>/import"
Conclusion
----------
At this point I ended up with the investigation, because the situation is the same as in case of using API.
Which is much more convenient to use and provides a better response in case of errors (I spent two days trying
to debug `No such file or directory [FILTERED]` error message).
At this point I ended up with the investigation, because the situation is the same as in
case of using API. Which is much more convenient to use and provides a better response
in case of errors (I spent two days trying to debug `No such file or directory
[FILTERED]` error message).

74
docs/pagure2gitlab/index.rst
View file

@ -4,85 +4,85 @@ Pagure to GitLab Importer
Purpose
-------
With Fedora and CentOS now having an official namespace on GitLab multiple projects wants to
migrate their repositories from `Pagure <https://pagure.io/>`_ to `GitLab <https://gitlab.com>`_.
This initiative is aimed to provide an easy way to migrate those projects.
With Fedora and CentOS now having an official namespace on GitLab multiple projects
wants to migrate their repositories from `Pagure <https://pagure.io/>`_ to `GitLab
<https://gitlab.com>`_. This initiative is aimed to provide an easy way to migrate those
projects.
Resources
---------
* Initiative proposal: https://pagure.io/cpe/initiatives-proposal/issue/25
* Pagure documentation: https://pagure.io/docs/pagure/
* GitLab documentation: https://docs.gitlab.com/
- Initiative proposal: https://pagure.io/cpe/initiatives-proposal/issue/25
- Pagure documentation: https://pagure.io/docs/pagure/
- GitLab documentation: https://docs.gitlab.com/
Requirements
------------
* Self-service tool
* Git commit history preservation
* Ability to migrate pagure issues
* 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
- Self-service tool
- Git commit history preservation
- Ability to migrate pagure issues
- 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
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
- Graphical UI
- Web interface
- Syncing the FAS usernames to GitLab as users migrate for already migrated projects
Investigation
-------------
Following are the investigations of Pagure options to export and GitLab options to import.
Following are the investigations of Pagure options to export and GitLab options to
import.
.. toctree::
:maxdepth: 1
pagure
pagureinfo
gitlab
gitlab_file_import
protop2g
Conclusions
-----------
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 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.
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 ticket` 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.
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 ticket` 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
----------------
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.
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
----------------
This work will need 2 developers.
The estimation for this project is 4 weeks.
This work will need 2 developers. The estimation for this project is 4 weeks.

122
docs/pagure2gitlab/pagure.rst
View file

@ -1,122 +0,0 @@
.. _pagure:
Exporting Namespace Assets From Pagure
====
A lot of projects related to Fedora Project and CentOS Project reside in Pagure
which makes it important for us to understand the ways they can be interacted
with and moved around when the need arises.
Elements for interaction
----
In this context, we are looking into interacting with the following elements -
Issue tickets
^^^^
These can either be requests for adding new features, reporting of a bug,
proposal of an idea or anything else. These need to be available in the place
where the namespace assets get transferred to, in order to retain the context
around the probable action items.
Repository assets
^^^^
These are the actual files stored in the Git repository that pertains to the
actual project. This can either be a codebase, a collection of documentation,
a group of artworks or anything else. This happens to be the primary subject
for the transfer.
We are avoiding interacting with the following elements -
Pull requests
^^^^
Not only does it require for the pull requests to be artificially created by a
stub user (say, a bot user of some kind as we cannot guarantee the availability
of the GitLab user pertaining to the related Pagure user) in the destination
namespace but it also needs the source of the pull request (which can either be
a fork of the source namespace of a branch inside the same repository) to be
available, which might not always be the case. We strongly recommend merging
all pending pull requests that are needed and closing those that are not,
before the transfer process begins.
Ways of interaction
----
The elements that we would want to interact with, can be done so using the
following ways.
Issue tickets
^^^^
* *Pagure API*
This provides an `extensive method <https://pagure.io/api/0/>`_ to `interact
with the issue tickets <https://pagure.io/api/0/#issues-tab>`_ pertaining to
a certain source namespace. This can be expanded upon to receive information
like issue title, issue content, assignees, tags, creation date, modified
date, comments etc. Depending on what information and how much amount of it
is requested from the API server, the interactions can be done quickly too,
paving the way for automation. The service does not seem to have rate
limiting too and hence, can be used without worry for interacting with bigger
repositories.
* *The good*
* A well structured API query with limited scope can ensure that multiple
requests are made and addressed quickly.
* This does not require any local storage space to be available in order to
make requests, unless caching is employed.
* *The bad*
* Extra assets bound to the issue ticket like images, documentation, media
files etc. cannot be reliably accessed.
* Service can be slow at times, leading to timeouts and hence, a condition
to address those during automation is needed.
* *Issues Git URL*
For the users that have a commit access to a certain source namespace, they
should be able to see an option for listing "Other Git URLs" on the project
page. Although Pagure provides methods to clone both "Issues" and "Pull
Requests" using those special Git URLs, we would only talk about that for the
former. For instance, the folks having a commit access to the
`fedora-websites <https://pagure.io/fedora-websites>`_ repository should be
able to access the issue tickets using the URL
`ssh://git@pagure.io/tickets/fedora-websites.git <ssh://git@pagure.io/tickets/fedora-websites.git>`_.
* *The good*
* A clone of the issues repository can help receive all the issue tickets
ever created in one fell swoop.
* Extra assets bound to the issue ticket like images, documentation, media
files etc. can be reliably accessed.
* *The bad*
* It can take a long time to fetch the issues repository in its entirety if
the repository has had too many of those.
* This mandatorily requires the use of a local storage space to be able to
clone and make changes locally before publish.
Repository assets
^^^^
* *Default Git URL*
Folks can access the repository assets of the source namespace using the
default Git URL. Depending on the availability of the API keys for the users,
they can choose to either interact with the repository assets with the use of
either the HTTPS URL (for example, it would be
`https://pagure.io/fedora-websites.git <https://pagure.io/fedora-websites.git>`_
for the fedora-websites source namespace) or the SSH URL (for example, it
would be
`ssh://git@pagure.io/fedora-websites.git <ssh://git@pagure.io/fedora-websites.git>`_
for the fedora-websites source namespace). We would not go in detail with the
advantages and disadvantages of this method as there seems to be only one way
to interact with repository assets.

107
docs/pagure2gitlab/pagureinfo.rst Normal file
View file

@ -0,0 +1,107 @@
.. _pagureinfo:
Exporting Namespace Assets From Pagure
======================================
A lot of projects related to Fedora Project and CentOS Project reside in Pagure which
makes it important for us to understand the ways they can be interacted with and moved
around when the need arises.
Elements for interaction
------------------------
In this context, we are looking into interacting with the following elements:
**Issue tickets**
These can either be requests for adding new features, reporting of a bug, proposal
of an idea or anything else. These need to be available in the place where the
namespace assets get transferred to, in order to retain the context around the
probable action items.
**Repository assets**
These are the actual files stored in the Git repository that pertains to the actual
project. This can either be a codebase, a collection of documentation, a group of
artworks or anything else. This happens to be the primary subject for the transfer.
We are avoiding interacting with the following elements
**Pull requests**
Not only does it require for the pull requests to be artificially created by a stub
user (say, a bot user of some kind as we cannot guarantee the availability of the
GitLab user pertaining to the related Pagure user) in the destination namespace but
it also needs the source of the pull request (which can either be a fork of the
source namespace of a branch inside the same repository) to be available, which
might not always be the case. We strongly recommend merging all pending pull
requests that are needed and closing those that are not, before the transfer process
begins.
Ways of interaction
-------------------
The elements that we would want to interact with, can be done so using the following
ways.
**Issue tickets**
- *Pagure API*
This provides an `extensive method <https://pagure.io/api/0/>`_ to `interact with
the issue tickets <https://pagure.io/api/0/#issues-tab>`_ pertaining to a certain
source namespace. This can be expanded upon to receive information like issue
title, issue content, assignees, tags, creation date, modified date, comments etc.
Depending on what information and how much amount of it is requested from the API
server, the interactions can be done quickly too, paving the way for automation.
The service does not seem to have rate limiting too and hence, can be used without
worry for interacting with bigger repositories.
- *The good*
- A well structured API query with limited scope can ensure that multiple
requests are made and addressed quickly.
- This does not require any local storage space to be available in order to make
requests, unless caching is employed.
- *The bad*
- Extra assets bound to the issue ticket like images, documentation, media files
etc. cannot be reliably accessed.
- Service can be slow at times, leading to timeouts and hence, a condition to
address those during automation is needed.
- *Issues Git URL*
For the users that have a commit access to a certain source namespace, they should
be able to see an option for listing "Other Git URLs" on the project page.
Although Pagure provides methods to clone both "Issues" and "Pull Requests" using
those special Git URLs, we would only talk about that for the former. For
instance, the folks having a commit access to the `fedora-websites
<https://pagure.io/fedora-websites>`_ repository should be able to access the
issue tickets using the URL ssh://git@pagure.io/tickets/fedora-websites.git.
- *The good*
- A clone of the issues repository can help receive all the issue tickets ever
created in one fell swoop.
- Extra assets bound to the issue ticket like images, documentation, media files
etc. can be reliably accessed.
- *The bad*
- It can take a long time to fetch the issues repository in its entirety if the
repository has had too many of those.
- This mandatorily requires the use of a local storage space to be able to clone
and make changes locally before publish.
Repository assets
~~~~~~~~~~~~~~~~~
- *Default Git URL*
Folks can access the repository assets of the source namespace using the default Git
URL. Depending on the availability of the API keys for the users, they can choose to
either interact with the repository assets with the use of either the HTTPS URL (for
example, it would be https://pagure.io/fedora-websites.git for the fedora-websites
source namespace) or the SSH URL (for example, it would be
ssh://git@pagure.io/fedora-websites.git for the fedora-websites source namespace). We
would not go in detail with the advantages and disadvantages of this method as there
seems to be only one way to interact with repository assets.

273
docs/pagure2gitlab/protop2g.rst
View file

@ -1,183 +1,178 @@
.. _protop2g:
Prototypes built
====
================
In order to be able to better understand what both the Pagure and GitLab APIs
are capable of and how they would be able to be of assistance in helping us
move assets from the source namespace to the destination namespace, we created
a prototype tool called "protop2g".
In order to be able to better understand what both the Pagure and GitLab APIs are
capable of and how they would be able to be of assistance in helping us move assets from
the source namespace to the destination namespace, we created a prototype tool called
"protop2g".
First rendition
----
---------------
The initial version of protop2g was hacked together in around a couple of days
using libraries like
`Requests <https://requests.readthedocs.io/>`_,
`Asciimatics <https://asciimatics.readthedocs.io/en/stable/intro.html>` etc. to
build an interactive text-based user interface.
The initial version of protop2g was hacked together in around a couple of days using
libraries like `Requests <https://requests.readthedocs.io/>`_, `Asciimatics
<https://asciimatics.readthedocs.io/en/stable/intro.html>` etc. to build an interactive
text-based user interface.
The following is a screenshot of the TUI screen where the users are given the
option to enter their source namespace location, API key for accessing the
source namespace location, destination namespace location, API key for
accessing the destination namespace location.
The following is a screenshot of the TUI screen where the users are given the option to
enter their source namespace location, API key for accessing the source namespace
location, destination namespace location, API key for accessing the destination
namespace location.
.. image:: ../_static/tui-protop2g-main.png
:target: ../_static/tui-protop2g-main.png
The following is a screenshot of the TUI screen where the users are shown the
metadata of both the source namespace and destination namespace. They are also
given the option to pick which assets they wish to interact with and transfer,
like repository data, issue tickets etc.
The following is a screenshot of the TUI screen where the users are shown the metadata
of both the source namespace and destination namespace. They are also given the option
to pick which assets they wish to interact with and transfer, like repository data,
issue tickets etc.
.. image:: ../_static/tui-protop2g-repo.png
:target: ../_static/tui-protop2g-repo.png
Unfortunately, this approach was scrapped due to the following reasons :-
* The TUI application approach would not allow for a simpler automation to help
folks who either own and/or maintain a lot of repositories.
* The logic for building the screens and sharing information around the screens
could possibly deviate from the actual feasibility checks.
* The colour palette and the elements used in the TUI might not be accessible
on a variety of terminal and console setups, that people have.
- The TUI application approach would not allow for a simpler automation to help folks
who either own and/or maintain a lot of repositories.
- The logic for building the screens and sharing information around the screens could
possibly deviate from the actual feasibility checks.
- The colour palette and the elements used in the TUI might not be accessible on a
variety of terminal and console setups, that people have.
Second rendition
----
----------------
After the initial version was archived in a different branch, the next version
of protop2g was created using libraries like
`Requests <https://requests.readthedocs.io/>`_,
`Click <https://click.palletsprojects.com/en/8.1.x/>`_,
`GitPython <https://gitpython.readthedocs.io/en/stable/tutorial.html>`_ etc. to
better facilitate an interactive command-line interface.
After the initial version was archived in a different branch, the next version of
protop2g was created using libraries like `Requests
<https://requests.readthedocs.io/>`_, `Click
<https://click.palletsprojects.com/en/8.1.x/>`_, `GitPython
<https://gitpython.readthedocs.io/en/stable/tutorial.html>`_ etc. to better facilitate
an interactive command-line interface.
The following is a console snippet of the help documentation of the overall
usage of the protop2g application.
The following is a console snippet of the help documentation of the overall usage of the
protop2g application.
.. code-block:: shell
.. code-block:: shell
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo --help
Usage: protop2g [OPTIONS] COMMAND [ARGS]...
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo --help
Usage: protop2g [OPTIONS] COMMAND [ARGS]...
Options:
-s, --srce TEXT Source namespace for importing assets from [required]
-d, --dest TEXT Destination namespace for exporting assets to [required]
-p, --pkey TEXT Pagure API key for accessing the source namespace
[required]
-g, --gkey TEXT GitLab API key for accessing the destination namespace
[required]
-f, --fusr TEXT Username of the account that owns the Pagure API key
[required]
-t, --tusr TEXT Username of the account that owns the GitLab API key
[required]
--version Show the version and exit.
--help Show this message and exit.
Options:
-s, --srce TEXT Source namespace for importing assets from [required]
-d, --dest TEXT Destination namespace for exporting assets to [required]
-p, --pkey TEXT Pagure API key for accessing the source namespace
[required]
-g, --gkey TEXT GitLab API key for accessing the destination namespace
[required]
-f, --fusr TEXT Username of the account that owns the Pagure API key
[required]
-t, --tusr TEXT Username of the account that owns the GitLab API key
[required]
--version Show the version and exit.
--help Show this message and exit.
Commands:
repo Initialize transfer of repository assets
tkts Initiate transfer of issue tickets
Commands:
repo Initialize transfer of repository assets
tkts Initiate transfer of issue tickets
The following is a console snippet of the help documentation for the "repo" command of
the protop2g application.
The following is a console snippet of the help documentation for the "repo"
command of the protop2g application.
The options for the command allow for people to be able to choose the branches that
should be transferred.
The options for the command allow for people to be able to choose the branches
that should be transferred.
.. code-block:: shell
.. code-block:: shell
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo --help
Usage: protop2g repo [OPTIONS]
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo --help
Usage: protop2g repo [OPTIONS]
Initialize transfer of repository assets
Initialize transfer of repository assets
Options:
-b, --brcs TEXT List of branches to extract
--help Show this message and exit.
Options:
-b, --brcs TEXT List of branches to extract
--help Show this message and exit.
The following is a console snippet of the help documentation for the "tkts" command of
the protop2g application.
The options for the command allow for people to be able to choose the nature of issues
they want to transfer.
The following is a console snippet of the help documentation for the "tkts"
command of the protop2g application.
.. code-block:: shell
The options for the command allow for people to be able to choose the nature of
issues they want to transfer.
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der tkts --help
Usage: protop2g tkts [OPTIONS]
.. code-block:: shell
Initiate transfer of issue tickets
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der tkts --help
Usage: protop2g tkts [OPTIONS]
Options:
-o, --open Extract only the open issue tickets
-c, --shut Extract only the closed issue tickets
-a, --full Extract all the issue tickets
--help Show this message and exit.
Initiate transfer of issue tickets
The following is a console snippet of the protop2g application at work, where it is
transferring the repository assets of all the branches from the source namespace to the
destination namespace.
Options:
-o, --open Extract only the open issue tickets
-c, --shut Extract only the closed issue tickets
-a, --full Extract all the issue tickets
--help Show this message and exit.
The following is a console snippet of the protop2g application at work, where
it is transferring the repository assets of all the branches from the source
namespace to the destination namespace.
.. code-block:: shell
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo
[ BUSY ] Requesting for source namespace metadata...
[ PASS ] Source namespace metadata acquisition succeeded!
Name: mdapi
Identifier: 221
Maintainer: Pierre-YvesChibon (ID pingou)
Location: https://pagure.io/mdapi
Address: https://t0xic0der:xxxxxxxxxxxxxxxxxx@pagure.io/mdapi.git
Created on: Thu Oct 22 16:33:58 2015
Last modified on: Thu Oct 22 16:33:58 2015
Tags: ['fedmsg', 'fedora-infra']
[ BUSY ] Requesting for destination namespace metadata...
[ PASS ] Destination namespace metadata acquisition succeeded!
Name: t0xic0der/protop2g-test
Identifier: 42823949
Maintainer: Akashdeep Dhar (ID t0xic0der)
Location: https://gitlab.com/t0xic0der/protop2g-test
Address: https://t0xic0der:xxxxxxxxxxxxxxxxxx@gitlab.com/t0xic0der/protop2g-test.git
Created on: 2023-01-23T16:18:30.217Z
Last modified on: 2023-01-28T18:44:14.075Z
Tags: []
[ BUSY ] Attempting source namespace assets clone...
[ PASS ] Source namespace assets clone succeeded!
Directory: /var/tmp/protop2g-tempsrce-a63xrvkc
Time taken: 6.77 second(s)
[ BUSY ] Attempting destination namespace assets clone...
[ PASS ] Destination namespace assets clone succeeded!
Directory: /var/tmp/protop2g-tempdest-w6_kxcbz
Time taken: 2.36 second(s)
[ BUSY ] Reading branches data from the locally cloned assets...
[ PASS ] Branches data reading succeeded!
Available in source namespace: 4 branch(es)
- (SRCE branch) HEAD
- (SRCE branch) master
- (SRCE branch) production
- (SRCE branch) staging
Available in destination namespace: 5 branch(es)
- (DEST branch) HEAD
- (DEST branch) main
- (DEST branch) master
- (DEST branch) production
- (DEST branch) staging
Requested for transferring: 0 branch(es)
[ BUSY ] Initializing namespace assets transfer...
[ WARN ] Transferring 4 available branches
[1/4] Branch 'HEAD' was transferred to the destination namespace
[2/4] Branch 'master' was transferred to the destination namespace
[3/4] Branch 'production' was transferred to the destination namespace
[4/4] Branch 'staging' was transferred to the destination namespace
Assets transferred: 4 branch(es) completed, 4 branch(es) requested
Time taken: 4.99 second(s)
[ PASS ] Namespace assets transfer succeeded!
.. code-block:: shell
(venv) [t0xic0der@fedorable protop2g]$ protop2g -g xxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxxxxxxx -s mdapi -d 42823949 -f t0xic0der -t t0xic0der repo
[ BUSY ] Requesting for source namespace metadata...
[ PASS ] Source namespace metadata acquisition succeeded!
Name: mdapi
Identifier: 221
Maintainer: Pierre-YvesChibon (ID pingou)
Location: https://pagure.io/mdapi
Address: https://t0xic0der:xxxxxxxxxxxxxxxxxx@pagure.io/mdapi.git
Created on: Thu Oct 22 16:33:58 2015
Last modified on: Thu Oct 22 16:33:58 2015
Tags: ['fedmsg', 'fedora-infra']
[ BUSY ] Requesting for destination namespace metadata...
[ PASS ] Destination namespace metadata acquisition succeeded!
Name: t0xic0der/protop2g-test
Identifier: 42823949
Maintainer: Akashdeep Dhar (ID t0xic0der)
Location: https://gitlab.com/t0xic0der/protop2g-test
Address: https://t0xic0der:xxxxxxxxxxxxxxxxxx@gitlab.com/t0xic0der/protop2g-test.git
Created on: 2023-01-23T16:18:30.217Z
Last modified on: 2023-01-28T18:44:14.075Z
Tags: []
[ BUSY ] Attempting source namespace assets clone...
[ PASS ] Source namespace assets clone succeeded!
Directory: /var/tmp/protop2g-tempsrce-a63xrvkc
Time taken: 6.77 second(s)
[ BUSY ] Attempting destination namespace assets clone...
[ PASS ] Destination namespace assets clone succeeded!
Directory: /var/tmp/protop2g-tempdest-w6_kxcbz
Time taken: 2.36 second(s)
[ BUSY ] Reading branches data from the locally cloned assets...
[ PASS ] Branches data reading succeeded!
Available in source namespace: 4 branch(es)
- (SRCE branch) HEAD
- (SRCE branch) master
- (SRCE branch) production
- (SRCE branch) staging
Available in destination namespace: 5 branch(es)
- (DEST branch) HEAD
- (DEST branch) main
- (DEST branch) master
- (DEST branch) production
- (DEST branch) staging
Requested for transferring: 0 branch(es)
[ BUSY ] Initializing namespace assets transfer...
[ WARN ] Transferring 4 available branches
[1/4] Branch 'HEAD' was transferred to the destination namespace
[2/4] Branch 'master' was transferred to the destination namespace
[3/4] Branch 'production' was transferred to the destination namespace
[4/4] Branch 'staging' was transferred to the destination namespace
Assets transferred: 4 branch(es) completed, 4 branch(es) requested
Time taken: 4.99 second(s)
[ PASS ] Namespace assets transfer succeeded!
Resources
----
---------
The project can be found over `here <https://github.com/t0xic0der/protop2g>`_.
The project can be found over `here <https://github.com/t0xic0der/protop2g>`__.