forked from forge/documentation
Split Pagure migration documentation and improve structure
- Split original Pagure migration doc into three documents: - Overview document with migration options - Standard repository migration guide - Private tickets migration guide - Add draft documentation warnings to all migration docs - Correct API key usage warnings (only needed for private tickets) - Update navigation to group Pagure migration docs together - Move issue dependencies migration under Pagure subsection - Crop screenshots to remove unnecessary content - Improve procedure formatting with headings and summaries - Specify Pagure.io instance name for clarity - Streamline API key creation steps with better instructions
This commit is contained in:
parent
c51d535130
commit
3e9b15c90d
8 changed files with 443 additions and 193 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 123 KiB After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 46 KiB |
|
|
@ -2,14 +2,14 @@
|
|||
** xref:create_org_profile_page.adoc[How to create an Organization Front Page]
|
||||
** xref:requesting_new_org_or_team.adoc[Requesting a New Organization and/or Team]
|
||||
** xref:using_http_auth.adoc[How to Clone a Repo with HTTPS]
|
||||
** xref:migrating_issue_dependencies.adoc[Migrating Issue Dependencies and Assignments from Pagure.io]
|
||||
* Admin Documentation
|
||||
** xref:creating_a_new_org.adoc[Creating a new Organization]
|
||||
** xref:creating_a_new_team.adoc[Creating a new Team]
|
||||
** xref:migration/pagure.adoc[Migrating from Pagure]
|
||||
*** xref:migration/pagure_repository.adoc[Migrate Repository from Pagure]
|
||||
*** xref:migration/pagure_private_tickets.adoc[Migrate Private Tickets from Pagure]
|
||||
*** xref:migrating_issue_dependencies.adoc[Migrating Issue Dependencies and Assignments from Pagure.io]
|
||||
** xref:migration/github.adoc[Migrating from GitHub]
|
||||
** xref:migration/gitlab.adoc[Migration from GitLab]
|
||||
* Admin Documentation
|
||||
** xref:creating_a_new_org.adoc[Creating a new Organization]
|
||||
** xref:creating_a_new_team.adoc[Creating a new Team]
|
||||
* Known Issues
|
||||
** xref:known_issue_cannot_create_user.adoc[Unable to Log in - "Cannot Create Account"]
|
||||
|
|
|
|||
|
|
@ -1,94 +1,120 @@
|
|||
= Migrating Repository from GitHub
|
||||
Akashdeep Dhar
|
||||
:revnumber: F42
|
||||
:revdate: 2025-09-16
|
||||
:category: Administration
|
||||
:page-aliases: github.adoc
|
||||
:imagesdir: ../../assets/images
|
||||
|
||||
== Introduction
|
||||
|
||||
With the introduction of Forgejo-based Forge in Fedora Infrastructure,
|
||||
maintainers of repositories involved with the Fedora Project's offerings are
|
||||
advised to move their repositories from GitHub to the newly introduced
|
||||
platform. This documentation covers the steps required to achieve this goal.
|
||||
= How to Migrate Repository from GitHub
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
**DRAFT DOCUMENTATION:** This documentation is currently in draft form and may not be fully tested and correct. Please verify all procedures before use and report any issues or inaccuracies.
|
||||
====
|
||||
|
||||
== Purpose
|
||||
|
||||
This document outlines the steps required to migrate repositories from GitHub
|
||||
to Fedora Forge, ensuring proper transfer of repository contents, issue tickets,
|
||||
and pull requests to the new Forgejo-based platform.
|
||||
|
||||
== Scope
|
||||
|
||||
This procedure applies to Fedora Project contributors who need to migrate
|
||||
repositories from GitHub to the new Fedora Forge platform. This includes
|
||||
subprojects, Special Interest Groups (SIGs), and other official Fedora Project
|
||||
repositories.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* *Repository Access:* You must have access to the source repository on GitHub
|
||||
and the necessary privileges to create repositories in the target organization
|
||||
on Fedora Forge.
|
||||
* *Organization Permissions:* You must have the ability to create repositories
|
||||
under the target namespace in Fedora Forge. If you don't have these
|
||||
privileges, consult a member from the relevant subproject or SIG, or contact
|
||||
the Fedora Infrastructure team.
|
||||
* *Personal Access Token:* You will need to create a personal access token in
|
||||
GitHub for the migration process.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As the Forgejo-based Fedora Forge houses only those repositories that are
|
||||
instrumental in the development, testing, maintenance and operating of the
|
||||
Fedora Project's offering of Fedora Linux, please use this for those
|
||||
repositories only -- and not for any other personal repositories.
|
||||
====
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As Forgejo does not support the creation of privately restricted issue tickets
|
||||
at this time, please take extra care while migrating those away from the source
|
||||
namespace on GitHub to ensure that confidential information contained in those
|
||||
issue tickets are not accidentally released out in the process.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
This guide assumes that you have the necessary privileges to be able to create
|
||||
a repository under the sought namespace in Fedora Forge. If that is not the
|
||||
case, please consult a member from the said subproject or SIG for the required
|
||||
privileges, or the Fedora Infrastructure team if you are involved.
|
||||
|
||||
[NOTE]
|
||||
We recommend migrating your other personal repositories present on Pagure over
|
||||
====
|
||||
We recommend migrating your other personal repositories present on GitHub over
|
||||
to Codeberg, which is also based on Forgejo and supports native migration of
|
||||
repository contents, issue tickets and pull requests from Pagure using the
|
||||
repository contents, issue tickets and pull requests from GitHub using the
|
||||
instructions provided here -- with some minor changes here and there.
|
||||
====
|
||||
|
||||
== Steps
|
||||
== Procedure
|
||||
|
||||
1. Log into GitHub and take note of the URL of the source repository.
|
||||
image:migration_github_01.png[]
|
||||
The migration process involves three main steps: creating a GitHub personal access token, accessing the Fedora Forge migration tool, and configuring the repository migration.
|
||||
|
||||
2. Click on your portrait and then navigate to the user settings.
|
||||
image:migration_github_02.png[]
|
||||
=== Create GitHub Personal Access Token
|
||||
|
||||
3. Head over to the *Developer settings* at the bottom of the sidebar.
|
||||
image:migration_github_03.png[]
|
||||
. Log into GitHub and navigate to the source repository you want to migrate.
|
||||
. Take note of the repository URL for later reference.
|
||||
image:migration_github_01.png[]
|
||||
. Click on your portrait in the top-right corner and navigate to user settings.
|
||||
image:migration_github_02.png[]
|
||||
. Head over to the *Developer settings* at the bottom of the sidebar.
|
||||
image:migration_github_03.png[]
|
||||
. Under the *Personal access tokens* section, select *Tokens (classic)*.
|
||||
image:migration_github_04.png[]
|
||||
. Under the *General new token* dropdown, click on the first option.
|
||||
image:migration_github_05.png[]
|
||||
. Provide your credentials to log into GitHub if required to do so.
|
||||
image:migration_github_06.png[]
|
||||
. Fill in the required details properly according to the request.
|
||||
image:migration_github_07.png[]
|
||||
. Select the sought repository from the *Repository access* section.
|
||||
image:migration_github_08.png[]
|
||||
. Choose your migration scope:
|
||||
.. If you want to migrate only the public repos, select the first option.
|
||||
image:migration_github_09.png[]
|
||||
.. If you want to migrate the entire namespace, select the second option.
|
||||
image:migration_github_10.png[]
|
||||
. Click on the *Generate token* button and confirm again when asked.
|
||||
image:migration_github_11.png[]
|
||||
. Copy the generated personal access token and keep it safely stored for use in the migration process.
|
||||
image:migration_github_12.png[]
|
||||
|
||||
4. Under the *Personal access tokens* section, select *Tokens (classic)*.
|
||||
image:migration_github_04.png[]
|
||||
=== Access Fedora Forge Migration Tool
|
||||
|
||||
5. Under the *General new token* dropdown, click on the first option.
|
||||
image:migration_github_05.png[]
|
||||
. Log into Fedora Forge using your Fedora Account credentials.
|
||||
. Navigate to the destination organization where you want to create the migrated repository.
|
||||
image:migration_github_13.png[]
|
||||
. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_github_14.png[]
|
||||
. Click on the *GitHub* button at the top of the migration page.
|
||||
image:migration_github_15.png[]
|
||||
|
||||
6. Provide your credentials to log into GitHub if required to do so.
|
||||
image:migration_github_06.png[]
|
||||
=== Configure Repository Migration
|
||||
|
||||
7. Fill in the required details properly according to the request.
|
||||
image:migration_github_07.png[]
|
||||
. Fill in the migration form with the information from your source repository:
|
||||
.. *Repository URL:* Enter the GitHub repository URL
|
||||
.. *Personal Access Token:* Enter the token you created earlier
|
||||
.. *Migration Items:* Select what to migrate (repositories, issues, pull requests, etc.)
|
||||
image:migration_github_16.png[]
|
||||
. Click on the *Migrate* button to start the migration.
|
||||
. Please be patient while the migration progresses gradually. Monitor the progress.
|
||||
image:migration_github_17.png[]
|
||||
. Wait for the migration to complete and verify successful migration.
|
||||
image:migration_github_18.png[]
|
||||
|
||||
8. Select the sought repository from the *Repository access* section.
|
||||
image:migration_github_08.png[]
|
||||
== Verification
|
||||
|
||||
9. If you want to migrate only the public repos, select the first option.
|
||||
image:migration_github_09.png[]
|
||||
|
||||
10. If you want to migrate the entire namespace, select the second option.
|
||||
image:migration_github_10.png[]
|
||||
|
||||
11. Click on the *Generate token* button and confirm again when asked.
|
||||
image:migration_github_11.png[]
|
||||
|
||||
12. Copy the personal access token and keep it aside safely for use.
|
||||
image:migration_github_12.png[]
|
||||
|
||||
13. Log into Forge and navigate to the destination namespace.
|
||||
image:migration_github_13.png[]
|
||||
|
||||
14. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_github_14.png[]
|
||||
|
||||
15. Click on the *GitHub* button at the top of the page.
|
||||
image:migration_github_15.png[]
|
||||
|
||||
16. Fill in the URL, token and items, and click on the *Migrate* button.
|
||||
image:migration_github_16.png[]
|
||||
|
||||
17. Please be patient while the migration progresses gradually.
|
||||
image:migration_github_17.png[]
|
||||
|
||||
18. Verify the successful migration of the repository once it is done.
|
||||
image:migration_github_18.png[]
|
||||
* Confirm that the migrated repository appears in the target organization on Fedora Forge.
|
||||
* Verify that all repository contents (code, branches, tags) have been successfully migrated.
|
||||
* Check that issue tickets and pull requests have been transferred correctly.
|
||||
* Test repository access permissions for team members.
|
||||
* Verify that the repository is accessible via Git clone operations.
|
||||
* Confirm that all GitHub-specific features have been properly converted to Forgejo equivalents.
|
||||
|
|
|
|||
|
|
@ -1,73 +1,106 @@
|
|||
= Migrating Repository from GitLab
|
||||
Akashdeep Dhar
|
||||
:revnumber: F42
|
||||
:revdate: 2025-09-16
|
||||
:category: Administration
|
||||
:page-aliases: gitlab.adoc
|
||||
:imagesdir: ../../assets/images
|
||||
|
||||
== Introduction
|
||||
|
||||
With the introduction of Forgejo-based Forge in Fedora Infrastructure,
|
||||
maintainers of repositories involved with the Fedora Project's offerings are
|
||||
advised to move their repositories from GitLab to the newly introduced
|
||||
platform. This documentation covers the steps required to achieve this goal.
|
||||
= How to Migrate Repository from GitLab
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
**DRAFT DOCUMENTATION:** This documentation is currently in draft form and may not be fully tested and correct. Please verify all procedures before use and report any issues or inaccuracies.
|
||||
====
|
||||
|
||||
== Purpose
|
||||
|
||||
This document outlines the steps required to migrate repositories from GitLab
|
||||
to Fedora Forge, ensuring proper transfer of repository contents, issue tickets,
|
||||
and pull requests to the new Forgejo-based platform.
|
||||
|
||||
== Scope
|
||||
|
||||
This procedure applies to Fedora Project contributors who need to migrate
|
||||
repositories from GitLab to the new Fedora Forge platform. This includes
|
||||
subprojects, Special Interest Groups (SIGs), and other official Fedora Project
|
||||
repositories.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* *Repository Access:* You must have access to the source repository on GitLab
|
||||
and the necessary privileges to create repositories in the target organization
|
||||
on Fedora Forge.
|
||||
* *Organization Permissions:* You must have the ability to create repositories
|
||||
under the target namespace in Fedora Forge. If you don't have these
|
||||
privileges, consult a member from the relevant subproject or SIG, or contact
|
||||
the Fedora Infrastructure team.
|
||||
* *Personal Access Token:* You will need to create a personal access token in
|
||||
GitLab for the migration process.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As the Forgejo-based Fedora Forge houses only those repositories that are
|
||||
instrumental in the development, testing, maintenance and operating of the
|
||||
Fedora Project's offering of Fedora Linux, please use this for those
|
||||
repositories only -- and not for any other personal repositories.
|
||||
====
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As Forgejo does not support the creation of privately restricted issue tickets
|
||||
at this time, please take extra care while migrating those away from the source
|
||||
namespace on GitLab to ensure that confidential information contained in those
|
||||
issue tickets are not accidentally released out in the process.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
This guide assumes that you have the necessary privileges to be able to create
|
||||
a repository under the sought namespace in Fedora Forge. If that is not the
|
||||
case, please consult a member from the said subproject or SIG for the required
|
||||
privileges, or the Fedora Infrastructure team if you are involved.
|
||||
|
||||
[NOTE]
|
||||
We recommend migrating your other personal repositories present on Pagure over
|
||||
====
|
||||
We recommend migrating your other personal repositories present on GitLab over
|
||||
to Codeberg, which is also based on Forgejo and supports native migration of
|
||||
repository contents, issue tickets and pull requests from Pagure using the
|
||||
repository contents, issue tickets and pull requests from GitLab using the
|
||||
instructions provided here -- with some minor changes here and there.
|
||||
====
|
||||
|
||||
== Steps
|
||||
== Procedure
|
||||
|
||||
1. Log into GitLab and take note of the URL of the source repository.
|
||||
image:migration_gitlab_01.png[]
|
||||
The migration process involves three main steps: creating a GitLab personal access token, accessing the Fedora Forge migration tool, and configuring the repository migration.
|
||||
|
||||
2. Head over to the *Settings* > *Access tokens* page from the extended sidebar.
|
||||
image:migration_gitlab_02.png[]
|
||||
=== Create GitLab Personal Access Token
|
||||
|
||||
3. Click on the *Add new token* button on the first section.
|
||||
image:migration_gitlab_03.png[]
|
||||
. Log into GitLab and navigate to the source repository you want to migrate.
|
||||
. Take note of the repository URL for later reference.
|
||||
image:migration_gitlab_01.png[]
|
||||
. Head over to the *Settings* > *Access tokens* page from the extended sidebar.
|
||||
image:migration_gitlab_02.png[]
|
||||
. Click on the *Add new token* button on the first section.
|
||||
image:migration_gitlab_03.png[]
|
||||
. Fill in the required information and select the necessary ACLs (Access Control Lists).
|
||||
image:migration_gitlab_04.png[]
|
||||
. Click the *Create* button to generate the personal access token.
|
||||
. Copy the generated personal access token and keep it safely stored for use in the migration process.
|
||||
image:migration_gitlab_05.png[]
|
||||
|
||||
4. Fill in the information and ACLs before clicking on the *Create* button.
|
||||
image:migration_gitlab_04.png[]
|
||||
=== Access Fedora Forge Migration Tool
|
||||
|
||||
5. Copy the personal access token and keep it aside safely for use.
|
||||
image:migration_gitlab_05.png[]
|
||||
. Log into Fedora Forge using your Fedora Account credentials.
|
||||
. Navigate to the destination organization where you want to create the migrated repository.
|
||||
image:migration_gitlab_06.png[]
|
||||
. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_gitlab_07.png[]
|
||||
. Click on the *GitLab* button at the top of the migration page.
|
||||
image:migration_gitlab_08.png[]
|
||||
|
||||
6. Log into Forge and navigate to the destination namespace.
|
||||
image:migration_gitlab_06.png[]
|
||||
=== Configure Repository Migration
|
||||
|
||||
7. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_gitlab_07.png[]
|
||||
. Fill in the migration form with the information from your source repository:
|
||||
.. *Repository URL:* Enter the GitLab repository URL
|
||||
.. *Personal Access Token:* Enter the token you created earlier
|
||||
.. *Repository Name:* Enter the desired name for the migrated repository
|
||||
.. *Description:* Copy the repository description from GitLab (optional)
|
||||
image:migration_gitlab_09.png[]
|
||||
. Click on the *Migrate repository* button to start the migration.
|
||||
image:migration_gitlab_10.png[]
|
||||
. Wait for the migration to complete. Monitor the progress and verify successful migration.
|
||||
image:migration_gitlab_11.png[]
|
||||
|
||||
8. Click on the *GitLab* button at the top of the page.
|
||||
image:migration_gitlab_08.png[]
|
||||
== Verification
|
||||
|
||||
9. Fill in the information taken from the source repository carefully.
|
||||
image:migration_gitlab_09.png[]
|
||||
|
||||
10. Click on the *Migrate repository* button and wait until it completes.
|
||||
image:migration_gitlab_10.png[]
|
||||
|
||||
11. Verify the successful migration of the repository once it is done.
|
||||
image:migration_gitlab_11.png[]
|
||||
* Confirm that the migrated repository appears in the target organization on Fedora Forge.
|
||||
* Verify that all repository contents (code, branches, tags) have been successfully migrated.
|
||||
* Check that issue tickets and pull requests have been transferred correctly.
|
||||
* Test repository access permissions for team members.
|
||||
* Verify that the repository is accessible via Git clone operations.
|
||||
* Confirm that all GitLab-specific features have been properly converted to Forgejo equivalents.
|
||||
|
|
|
|||
|
|
@ -1,86 +1,84 @@
|
|||
= Migrating Repository from Pagure
|
||||
Akashdeep Dhar
|
||||
:revnumber: F42
|
||||
:revdate: 2025-09-15
|
||||
:category: Administration
|
||||
:page-aliases: pagure.adoc
|
||||
:imagesdir: ../../assets/images
|
||||
|
||||
== Introduction
|
||||
|
||||
With the introduction of Forgejo-based Fedora Forge in Fedora Infrastructure
|
||||
and the imminent decommissioning of the Pagure service, it is strongly
|
||||
recommended for the repositories housed over there to be moved over to the
|
||||
newly introduced platform. This documentation covers the steps required to
|
||||
achieve this goal.
|
||||
= Migrating from Pagure
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
**DRAFT DOCUMENTATION:** This documentation is currently in draft form and may not be fully tested and correct. Please verify all procedures before use and report any issues or inaccuracies.
|
||||
====
|
||||
|
||||
== Purpose
|
||||
|
||||
This document provides an overview of migrating repositories from Pagure to Fedora Forge, with links to specific migration procedures based on your repository's content and requirements.
|
||||
|
||||
== Scope
|
||||
|
||||
This overview applies to Fedora Project contributors who need to migrate repositories from the legacy Pagure service to the new Fedora Forge platform. This includes subprojects, Special Interest Groups (SIGs), and other official Fedora Project repositories.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As the Forgejo-based Fedora Forge houses only those repositories that are
|
||||
instrumental in the development, testing, maintenance and operating of the
|
||||
Fedora Project's offering of Fedora Linux, please use this for those
|
||||
repositories only -- and not for any other personal repositories.
|
||||
|
||||
[WARNING]
|
||||
As Forgejo does not support the creation of privately restricted issue tickets
|
||||
at this time, migrating repositories having them would require a workaround of
|
||||
creating two destination repositories - one publicly accessible and one
|
||||
privately restricted, to ensure the confidentiality of those issue tickets.
|
||||
|
||||
[NOTE]
|
||||
This guide assumes that you have the necessary privileges to be able to create
|
||||
a repository under the sought namespace in Fedora Forge. If that is not the
|
||||
case, please consult a member from the said subproject or SIG for the required
|
||||
privileges, or the Fedora Infrastructure team if you are involved.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
We recommend migrating your other personal repositories present on Pagure over
|
||||
to Codeberg, which is also based on Forgejo and supports native migration of
|
||||
repository contents, issue tickets and pull requests from Pagure using the
|
||||
instructions provided here -- with some minor changes here and there.
|
||||
====
|
||||
|
||||
== Steps
|
||||
== Migration Options
|
||||
|
||||
1. Log into Pagure and take note of the URL of the source repository.
|
||||
image:migration_pagure_01.png[]
|
||||
Choose the appropriate migration procedure based on your repository's content:
|
||||
|
||||
2. Click on your portrait and then navigate to the user settings.
|
||||
image:migration_pagure_02.png[]
|
||||
=== Standard Repository Migration
|
||||
|
||||
3. Provide your credentials to log into Pagure if required to do so.
|
||||
image:migration_pagure_03.png[]
|
||||
Use this procedure for repositories that contain only public content (code, public issues, pull requests).
|
||||
|
||||
4. In the API Keys section, click on the *Create new API key* button.
|
||||
image:migration_pagure_04.png[]
|
||||
* **When to use:** Repository has no private or restricted issue tickets
|
||||
* **Result:** Single public repository with all content migrated
|
||||
* **Documentation:** xref:pagure_repository.adoc[How to Migrate Repository from Pagure]
|
||||
|
||||
5. Select all necessary ACLs before clicking on the *Create* button.
|
||||
image:migration_pagure_05.png[]
|
||||
=== Private Tickets Migration
|
||||
|
||||
6. Copy the API key thus created and keep it aside safely for use.
|
||||
image:migration_pagure_06.png[]
|
||||
Use this procedure for repositories that contain private or restricted issue tickets that need to be kept confidential.
|
||||
|
||||
7. Log into Forge and navigate to the destination namespace.
|
||||
image:migration_pagure_07.png[]
|
||||
* **When to use:** Repository contains private/restricted issue tickets
|
||||
* **Result:** Separate private repository containing only the private tickets
|
||||
* **Documentation:** xref:pagure_private_tickets.adoc[How to Migrate Private Tickets from Pagure to a New Private Repository]
|
||||
|
||||
8. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_pagure_08.png[]
|
||||
[WARNING]
|
||||
====
|
||||
As Forgejo does not support the creation of privately restricted issue tickets
|
||||
within public repositories, repositories with private tickets require a separate
|
||||
private repository to maintain confidentiality.
|
||||
====
|
||||
|
||||
9. Click on the *Pagure* button at the bottom of the page.
|
||||
image:migration_pagure_09.png[]
|
||||
== Prerequisites
|
||||
|
||||
10. Fill in the information taken from the source repository carefully.
|
||||
image:migration_pagure_10.png[]
|
||||
Before starting any migration, ensure you have:
|
||||
|
||||
11. Leave the token empty and click on the *Migrate repository* button.
|
||||
image:migration_pagure_11.png[]
|
||||
* *Repository Access:* Access to the source repository on Pagure
|
||||
* *Organization Permissions:* Ability to create repositories in the target organization on Fedora Forge
|
||||
* *API Key:* (For private tickets only) A Pagure API key for accessing private content
|
||||
* *Private Repository Access:* (For private tickets) Permissions to create private repositories
|
||||
|
||||
12. This should create a repository with the publicly accessible data.
|
||||
image:migration_pagure_12.png[]
|
||||
[IMPORTANT]
|
||||
====
|
||||
**API Key Usage:** API keys are only required for migrating private tickets. Do NOT use an API key for standard repository migration, as this will cause the migrator to import only private tickets instead of the full repository content. If you haven't set the repository to private, these private tickets will become publicly visible, potentially exposing confidential information.
|
||||
====
|
||||
|
||||
13. Return to the *New migration* page and click on the *Pagure* button.
|
||||
image:migration_pagure_09.png[]
|
||||
== Next Steps
|
||||
|
||||
14. Fill the name and token, visibility appropriately before starting.
|
||||
image:migration_pagure_13.png[]
|
||||
1. **Identify your repository type:** Determine if your repository contains private tickets
|
||||
2. **Choose the appropriate procedure:** Follow the relevant migration guide above
|
||||
3. **Follow the step-by-step instructions:** Each guide provides detailed procedures
|
||||
4. **Verify the migration:** Ensure all content has been transferred correctly
|
||||
|
||||
15. This should create a repository with the privately restricted data.
|
||||
image:migration_pagure_14.png[]
|
||||
== Additional Resources
|
||||
|
||||
* xref:github.adoc[How to Migrate Repository from GitHub]
|
||||
* xref:gitlab.adoc[How to Migrate Repository from GitLab]
|
||||
* xref:../known_issue_cannot_create_user.adoc[Known Issue: Unable to Log in - "Cannot Create Account"]
|
||||
|
|
|
|||
109
modules/ROOT/pages/migration/pagure_private_tickets.adoc
Normal file
109
modules/ROOT/pages/migration/pagure_private_tickets.adoc
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
= How to Migrate Private Tickets from Pagure to a New Private Repository
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
**DRAFT DOCUMENTATION:** This documentation is currently in draft form and may not be fully tested and correct. Please verify all procedures before use and report any issues or inaccuracies.
|
||||
====
|
||||
|
||||
== Purpose
|
||||
|
||||
This document outlines the steps required to migrate private/restricted issue tickets from a Pagure.io repository to a new private repository on Fedora Forge, ensuring the confidentiality of sensitive information while maintaining access control.
|
||||
|
||||
== Scope
|
||||
|
||||
This procedure applies to Fedora Project contributors who need to migrate repositories containing private or restricted issue tickets from Pagure.io to Fedora Forge. This is necessary because Forgejo does not support privately restricted issue tickets within public repositories.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* *Repository Access:* You must have access to the source repository on Pagure.io
|
||||
and the necessary privileges to create repositories in the target organization
|
||||
on Fedora Forge.
|
||||
* *Organization Permissions:* You must have the ability to create repositories
|
||||
under the target namespace in Fedora Forge. If you don't have these
|
||||
privileges, consult a member from the relevant subproject or SIG, or contact
|
||||
the Fedora Infrastructure team.
|
||||
* *API Key:* You will need to create an API key in Pagure.io for the migration
|
||||
process.
|
||||
* *Private Repository Access:* You must have permissions to create private repositories in the target organization.
|
||||
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
As Forgejo does not support the creation of privately restricted issue tickets
|
||||
at this time, migrating repositories having them requires creating a separate
|
||||
private repository to ensure the confidentiality of those issue tickets.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
This procedure assumes you have already migrated the main repository content
|
||||
using the standard migration process. This document focuses specifically on
|
||||
migrating private tickets to a separate private repository.
|
||||
====
|
||||
|
||||
== Procedure
|
||||
|
||||
The private ticket migration process involves four main steps: creating a Pagure.io API key, accessing the Fedora Forge migration tool, configuring the private repository migration, and setting up proper access controls.
|
||||
|
||||
=== Create Pagure.io API Key
|
||||
|
||||
. Log into Pagure.io and navigate to the source repository containing private tickets, taking note of the repository URL for later reference.
|
||||
. Click on your portrait in the top-right corner and navigate to user settings.
|
||||
image:migration_pagure_02.png[]
|
||||
. In the API Keys section, click on the *Create new API key* button.
|
||||
image:migration_pagure_04.png[]
|
||||
. Fill in the "Create a new token" form with the following information:
|
||||
.. *Description:* Enter a descriptive name for the API key (e.g., "Fedora Forge Migration")
|
||||
.. *Expiration Date:* Set an appropriate expiration date for security purposes
|
||||
.. *ACLs:* Select all necessary ACLs (Access Control Lists) for repository access
|
||||
.. Click the *Create* button to generate the API key.
|
||||
image:migration_pagure_05.png[]
|
||||
. Copy the generated API key and keep it safely stored for use in the migration process.
|
||||
image:migration_pagure_06.png[]
|
||||
|
||||
=== Access Fedora Forge Migration Tool
|
||||
|
||||
. Log into Fedora Forge using your Fedora Account credentials.
|
||||
. Navigate to the destination organization where you want to create the private repository.
|
||||
image:migration_pagure_07.png[]
|
||||
. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_pagure_08.png[]
|
||||
. Click on the *Pagure* button at the bottom of the migration page.
|
||||
image:migration_pagure_09.png[]
|
||||
|
||||
=== Configure Private Repository Migration
|
||||
|
||||
. Fill in the migration form with the information from your source repository:
|
||||
.. *Repository Name:* Enter a descriptive name for the private repository (e.g., `original-repo-private-tickets`)
|
||||
.. *Clone URL:* Enter the Git clone URL from your Pagure repository
|
||||
.. *Description:* Add a description indicating this contains private tickets (e.g., "Private tickets from [original-repo]")
|
||||
.. *Visibility:* Set to private for restricted content
|
||||
image:migration_pagure_13.png[]
|
||||
. Enter the API key you created earlier in the token field.
|
||||
. Click on the *Migrate repository* button to start the migration.
|
||||
. Wait for the migration to complete. This creates a private repository with all tickets, including private ones.
|
||||
image:migration_pagure_14.png[]
|
||||
|
||||
=== Configure Access Controls
|
||||
|
||||
. Navigate to the newly created private repository.
|
||||
. Go to the repository settings and configure access controls:
|
||||
.. Add only authorized team members who need access to private tickets
|
||||
.. Ensure proper permission levels are set (typically Read access for ticket viewing)
|
||||
.. Document who has access and why for audit purposes
|
||||
|
||||
== Verification
|
||||
|
||||
* Confirm that the private repository appears in the target organization on Fedora Forge.
|
||||
* Verify that private tickets are only visible to authorized users.
|
||||
* Check that all private tickets have been transferred correctly.
|
||||
* Test repository access permissions for team members.
|
||||
* Verify that unauthorized users cannot access the private repository.
|
||||
* Confirm that the private repository is accessible via Git clone operations for authorized users.
|
||||
|
||||
== Important Notes
|
||||
|
||||
* **Separate Repository:** This creates a completely separate repository containing only the private tickets, not the main codebase.
|
||||
* **Access Control:** Ensure only authorized personnel have access to the private repository.
|
||||
* **Documentation:** Document the relationship between the main repository and the private tickets repository.
|
||||
* **Maintenance:** Consider how to handle future private tickets - they may need to be created in the private repository going forward.
|
||||
84
modules/ROOT/pages/migration/pagure_repository.adoc
Normal file
84
modules/ROOT/pages/migration/pagure_repository.adoc
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
= How to Migrate Repository from Pagure
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
**DRAFT DOCUMENTATION:** This documentation is currently in draft form and may not be fully tested and correct. Please verify all procedures before use and report any issues or inaccuracies.
|
||||
====
|
||||
|
||||
== Purpose
|
||||
|
||||
This document outlines the steps required to migrate repositories from Pagure
|
||||
to Fedora Forge, ensuring proper transfer of repository contents, issue tickets,
|
||||
and pull requests to the new Forgejo-based platform.
|
||||
|
||||
== Scope
|
||||
|
||||
This procedure applies to Fedora Project contributors who need to migrate
|
||||
repositories from the legacy Pagure service to the new Fedora Forge platform.
|
||||
This includes subprojects, Special Interest Groups (SIGs), and other official
|
||||
Fedora Project repositories.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* *Repository Access:* You must have access to the source repository on Pagure
|
||||
and the necessary privileges to create repositories in the target organization
|
||||
on Fedora Forge.
|
||||
* *Organization Permissions:* You must have the ability to create repositories
|
||||
under the target namespace in Fedora Forge. If you don't have these
|
||||
privileges, consult a member from the relevant subproject or SIG, or contact
|
||||
the Fedora Infrastructure team.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
**Do NOT create or use an API key for standard repository migration.** The API key is only needed for migrating private tickets. Using an API key in the standard migration will cause the migrator to import only private tickets instead of the full repository content. If you haven't set the repository to private, these private tickets will become publicly visible.
|
||||
====
|
||||
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
We recommend migrating your other personal repositories present on Pagure over
|
||||
to Codeberg, which is also based on Forgejo and supports native migration of
|
||||
repository contents, issue tickets and pull requests from Pagure using the
|
||||
instructions provided here -- with some minor changes here and there.
|
||||
====
|
||||
|
||||
== Procedure
|
||||
|
||||
The migration process involves two main steps: accessing the Fedora Forge migration tool and configuring the repository migration.
|
||||
|
||||
=== Access Fedora Forge Migration Tool
|
||||
|
||||
. Log into Fedora Forge using your Fedora Account credentials.
|
||||
. Navigate to the destination organization where you want to create the migrated repository.
|
||||
image:migration_pagure_07.png[]
|
||||
. Click on the *New migration* button to begin the migration process.
|
||||
image:migration_pagure_08.png[]
|
||||
. Click on the *Pagure* button at the bottom of the migration page.
|
||||
image:migration_pagure_09.png[]
|
||||
|
||||
=== Configure Repository Migration
|
||||
|
||||
. Fill in the migration form with the information from your source repository:
|
||||
.. *Repository Name:* Enter the desired name for the migrated repository
|
||||
.. *Clone URL:* Enter the Git clone URL from your Pagure repository
|
||||
.. *Description:* Copy the repository description from Pagure (optional)
|
||||
.. *Visibility:* Set to public for publicly accessible content
|
||||
image:migration_pagure_10.png[]
|
||||
. **Leave the token field empty** - this is crucial for standard repository migration.
|
||||
+
|
||||
[WARNING]
|
||||
====
|
||||
**Do NOT enter an API key in the token field.** If you provide an API key here, the migrator will only import private tickets instead of the full repository content (code, public issues, pull requests, etc.). This will result in an incomplete migration. Additionally, if you haven't set the repository to private, these private tickets will become publicly visible, potentially exposing confidential information.
|
||||
====
|
||||
. Click on the *Migrate repository* button to start the migration.
|
||||
image:migration_pagure_11.png[]
|
||||
. Wait for the migration to complete. This creates a repository with all publicly accessible data.
|
||||
image:migration_pagure_12.png[]
|
||||
|
||||
== Verification
|
||||
|
||||
* Confirm that the migrated repository appears in the target organization on Fedora Forge.
|
||||
* Verify that all repository contents (code, branches, tags) have been successfully migrated.
|
||||
* Check that issue tickets and pull requests have been transferred correctly.
|
||||
* Test repository access permissions for team members.
|
||||
* Verify that the repository is accessible via Git clone operations.
|
||||
Loading…
Add table
Add a link
Reference in a new issue