Migrate all Quality repos to Forgejo

adamwill commented

2025-10-28 22:49:27 +00:00

Owner

We need to migrate all our repos to Fedora Forge - Quality.

Migration documentation: https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure/

Migration showstoppers:
a) There are private tickets in the repo which need to be migrated. Private tickets can only be migrated to a separate private repository.

Migration checklist

Look at showstoppers above, don't proceed for affected repos.
Read migration documentation, in particular public repo migration and migrating dependencies and assignments
When in doubt, test migration in Forge Staging first.
Use the New Migration button in https://forge.fedoraproject.org/quality to start the migration
Verify that everything has been migrated correctly (code, branches, tags, issues, pull requests, milestones, etc).
Copy over the project URL for Forge manually. From Pagure project -> Settings -> Project Details -> Project's url into Forge project -> Settings -> Repository -> Website.
Migrate assignees and dependencies. Verify that it worked correctly. Also inspect script output.
Use forge_migrate_story_points.py to migrate story points. Verify that it worked correctly. Also inspect script output.
Use pagure_add_migration_comment.py to add a migration comment to all tickets in Pagure. Verify that they it worked correctly. Also inspect script output.
In Pagure project -> Settings -> Project Options, enable Issue tracker read only and disable Pull requests.
Replace the README contents of the repo with a message:

** This project has been moved to: $NEWURL ** 

This repository is now in archive mode only. There will be no further responses to any issues or pull requests in this repository. The development will only be taken forward in the new repository.

If you use any kanban boards in the source repo, you need to re-create them manually in the new Forge repo.
Go through all source code, internal and external documentation, RPM spec files, and any other locations, find references to the old repo and replace it with the new URL. (This might take a while, perhaps file a ticket for this so that you don't forget about it to do it later).
If your new repo uses CI, enable it. You can get inspiration from Adam's howto blogpost, the fedfind repo and Forgejo Actions documentation.

Notes for migration

Project URL doesn't get migrated automatically, needs to be done manually. See forge#279.
Pagure tickets don't get a link or redirect to the new location. See forge#277. We've implemented our own solution, see the checklist.
Pull requests from forks are not migrated, i.e. you'll not have access to the forked branch. You need to pull from the fork and merge the changes manually.
Pagure boards (kanban) don't get migrated to Forgejo projects. See forge#280.
Ticket assignees and dependencies (blocks/depends on) are not migrated by default, it needs an extra script execution. ~~See forge#282 regarding Forge API token generation.~~ I (kparal) tested the script and it works.
Our story_points field is not migrated. We've implemented our own solution, see the checklist.
When testing the migration to Forge staging, note that attachments might not appear properly, unless you source the repo from pagure.stg (ticket). But you can test the attachments by manually changing forge.stg to forge in the URL.
There are organization-wide labels and per-project labels. For the initial migration, we'll use per-project labels everywhere, but afterwards, we'll likely want to convert them in most projects to org-wide labels (some part of them, at least). New scripts will be needed for that.
Don't forget to enable email notifications in Fedora Forge for your account (they are disabled by default).

We need to migrate all our repos to [Fedora Forge - Quality](https://forge.fedoraproject.org/quality). Migration documentation: https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure/ **Migration showstoppers:** a) There are private tickets in the repo which need to be migrated. Private tickets can only be migrated [to a separate private repository](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure_private_tickets/). ### Migration checklist 1. Look at showstoppers above, don't proceed for affected repos. 2. Read [migration documentation](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure/), in particular [public repo migration](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure_repository/) and [migrating dependencies and assignments](https://docs.fedoraproject.org/en-US/forge-documentation/migrating_issue_dependencies/) 3. When in doubt, test migration in [Forge Staging](https://forge.stg.fedoraproject.org/quality) first. 4. Use the New Migration button in https://forge.fedoraproject.org/quality to start the migration 5. Verify that everything has been migrated correctly (code, branches, tags, issues, pull requests, milestones, etc). 6. Copy over the project URL for Forge manually. From *Pagure project -> Settings -> Project Details -> Project's url* into *Forge project -> Settings -> Repository -> Website*. 7. Migrate [assignees and dependencies](https://docs.fedoraproject.org/en-US/forge-documentation/migrating_issue_dependencies/). Verify that it worked correctly. Also inspect script output. 8. Use [forge_migrate_story_points.py](https://forge.fedoraproject.org/quality/forge-helpers) to migrate story points. Verify that it worked correctly. Also inspect script output. 9. Use [pagure_add_migration_comment.py](https://forge.fedoraproject.org/quality/forge-helpers) to add a migration comment to all tickets in Pagure. Verify that they it worked correctly. Also inspect script output. 10. In *Pagure project -> Settings -> Project Options*, enable *Issue tracker read only* and disable *Pull requests*. 11. Replace the README contents of the repo with a message: ``` ** This project has been moved to: $NEWURL ** This repository is now in archive mode only. There will be no further responses to any issues or pull requests in this repository. The development will only be taken forward in the new repository. ``` 12. If you use any kanban boards in the source repo, you need to re-create them manually in the new Forge repo. 13. Go through all source code, internal and external documentation, RPM spec files, and any other locations, find references to the old repo and replace it with the new URL. (This might take a while, perhaps file a ticket for this so that you don't forget about it to do it later). 14. If your new repo uses CI, enable it. You can get inspiration from [Adam's howto blogpost](https://www.happyassassin.net/posts/2026/01/19/ci-and-llm-review-on-fedora-forge-with-forgejo-actions/), the [fedfind repo](https://forge.fedoraproject.org/quality/fedfind/src/branch/main/.forgejo/workflows) and [Forgejo Actions documentation](https://forgejo.org/docs/next/user/actions/quick-start/). ### Notes for migration * Project URL doesn't get migrated automatically, needs to be done manually. See [forge#279](https://forge.fedoraproject.org/forge/forge/issues/279). * Pagure tickets don't get a link or redirect to the new location. See [forge#277](https://forge.fedoraproject.org/forge/forge/issues/277). We've implemented our own solution, see the checklist. * Pull requests from forks are not migrated, i.e. you'll not have access to the forked branch. You need to pull from the fork and merge the changes manually. * Pagure boards (kanban) don't get migrated to Forgejo projects. See [forge#280](https://forge.fedoraproject.org/forge/forge/issues/280). * Ticket assignees and dependencies (blocks/depends on) are not migrated by default, it needs [an extra script execution](https://docs.fedoraproject.org/en-US/forge-documentation/migrating_issue_dependencies/). ~~See [forge#282](https://forge.fedoraproject.org/forge/forge/issues/282) regarding Forge API token generation.~~ I (kparal) tested the script and it works. * Our `story_points` field is not migrated. We've implemented our own solution, see the checklist. * When testing the migration to Forge staging, note that attachments might not appear properly, unless you source the repo from pagure.stg ([ticket](https://forge.fedoraproject.org/forge/forge/issues/321#issuecomment-259425)). But you can test the attachments by manually changing `forge.stg` to `forge` in the URL. * There are organization-wide labels and per-project labels. For the initial migration, we'll use per-project labels everywhere, but afterwards, we'll likely want to convert them in most projects to org-wide labels (some part of them, at least). New scripts will be needed for that. * Don't forget to **[enable email notifications](https://docs.fedoraproject.org/en-US/forge-documentation/email_notifications/)** in Fedora Forge for your account (they are disabled by default). ### List of migration tickets for all Quality-related repos [⚠️] https://pagure.io/fedora-qa/blocker-review/issue/2009 **BLOCKED by [required engineering work](https://forge.fedoraproject.org/quality/blockerbugs/issues/296)** [✅] https://pagure.io/fedora-qa/check-compose/issue/3 [✅] https://pagure.io/fedora-qa/fedfind/issue/27 [✅] https://pagure.io/fedora-qa/python-wikitcms/issue/12 [✅] https://pagure.io/fedora-qa/relval/issue/48 [✅] https://pagure.io/issuebot/issue/16 [✅] https://pagure.io/fedora-easy-karma/issue/71 [✅] https://pagure.io/fedora-qa/createhdds/issue/16 [✅] https://pagure.io/fedora-qa/releasestream/issue/8 [✅] https://pagure.io/fedora-qa/python-ci_messages/issue/2 [✅] https://pagure.io/fedora-qa/relvalconsumer/issue/7 [✅] https://pagure.io/taskotron/resultsdb_conventions/issue/6 [✅] https://pagure.io/fedora-qa/testdays/issue/3 [✅] https://pagure.io/fedora-qa/qa-docs/issue/9 [✅] https://pagure.io/fedora-qa/qa-stats/issue/3 [✅] https://pagure.io/fedora-qa/qa-misc/issue/10 [✅] https://pagure.io/fedora-qa/testdays-web/issue/69 [✅] https://pagure.io/fedora-qa/openqa_testdata/issue/2 [✅] https://pagure.io/fedora-qa/fedora-release-autotest/issue/1 [✅] https://pagure.io/fedora-qa/blockerbugs/issue/295 [✅] https://pagure.io/fedora-qa/issue/839 [✅] https://pagure.io/fedora_nightlies/issue/14 [✅] https://pagure.io/fedora-qa/fedora_openqa/issue/114 [✅] https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/446 [❌] autocloudreporter - OBSOLETE [❌] autoqa - OBSOLETE [❌] beaker-tools - OBSOLETE [❌] commitfinder - OBSOLETE [❌] fedora-beaker-tests - OBSOLETE [❌] fedora-desktop-testing - OBSOLETE [❌] fedora-kiwi-instance-docs - OBSOLETE [❌] fedora-tcms-migration - OBSOLETE [❌] fedora-testcases - OBSOLETE [❌] landingpage - OBSOLETE ([ticket](https://pagure.io/fedora-qa/issue/859)) [❌] lolz_and_roffle - OBSOLETE [❌] modularity_testing_scripts - OBSOLETE [❌] openqa_docker - OBSOLETE [❌] switchcheck - OBSOLETE [❌] testcase-playbook - OBSOLETE / unpopulated [❌] uf-monitor - OBSOLETE [❌] https://pagure.io/fedora-qa/openQA_scripting_tool/issue/1 - not needed now [❌] https://pagure.io/fedora-qa/autococonut/issue/15 - not needed now [❌] https://pagure.io/fedora-qa/fedora-glossary/issue/1 - not needed now [❌] https://pagure.io/fedora-qa/test_cases/issue/2 - not needed now [❌] https://pagure.io/fedora-qa/flask_skeleton/issue/2 - not needed now [❌] cloud-atomic-ansible-tests - OBSOLETE [❌] fedora-gooey-karma - ARCHIVED / OBSOLETE [❌] kanban - OBSOLETE [❌] motd - OBSOLETE [❌] phabarchive - ARCHIVED; probably not needed since we have https://fedorapeople.org/groups/qa/phabarchive/ [❌] https://pagure.io/fedora-qa/_private/issue/37 - no longer needed, private issues are done in Jira now [❌] taskotron-fedora-cloud-tests - OBSOLETE [❌] windows-ad-integration-testing - probably OBSOLETE; we eventually implemented the 'AD' testing using Samba [❌] qa-make - OBSOLETE [❌] oraculum-client - NOT IMPLEMENTED [❌] https://pagure.io/fedora-qa/oraculum/issue/221 - ORPHANED ([ticket](https://pagure.io/fedora-qa/issue/860)) [❌] https://pagure.io/fedora-qa/packager_dashboard/issue/187 - ORPHANED ([ticket](https://pagure.io/fedora-qa/issue/860)) [❌] https://pagure.io/fedora-qa/openqa_classifier/issue/1 - mostly Tim's project, we don't need it at this moment. The future of it will be discussed with Tim at some point.

👍 1

adamwill commented

2025-10-28 22:49:33 +00:00

Author

Owner

Metadata Update from @adamwill:

Custom field story_points adjusted to 5

**Metadata Update from @adamwill**: - Custom field story_points adjusted to 5

adamwill commented

2025-10-28 22:52:53 +00:00

Author

Owner

Also we probably need an org in forgejo.

kparal commented

2025-10-29 10:54:04 +00:00

Owner

Yes, we need an org first. I was planning to look into it and figure out the required structure and naming and everything first. Feel free to beat me to it, if you wish.

adamwill commented

2025-10-29 18:37:59 +00:00

Author

Owner

Filed https://pagure.io/fedora-infrastructure/issue/12875 requesting an org, following the draft doc at https://docs.fedoraproject.org/ga/forge-documentation/requesting_new_org_or_team/ .

humaton commented

2025-11-05 10:06:05 +00:00

The quality organization was created on both stg and prod deployments. Group mappings PR needs to get merged, and we need to fix one more issue with Anubis before we can move this forward. forge/forge#264

The quality organization was created on both stg and prod deployments. Group mappings PR needs to get merged, and we need to fix one more issue with Anubis before we can move this forward. https://forge.fedoraproject.org/forge/forge/issues/264

kparal commented

2025-11-06 06:28:56 +00:00

Owner

Thanks for update, Tomas.

Another repo I'd like to migrate (and takeownership of) is
https://pagure.io/issuebot

I'll update the ticket description, add it, and convert it into checkboxes.

Thanks for update, Tomas. Another repo I'd like to migrate (and takeownership of) is https://pagure.io/issuebot I'll update the ticket description, add it, and convert it into checkboxes.

kparal commented

2025-11-06 06:43:14 +00:00

Owner

Metadata Update from @kparal:

Custom field story_points adjusted to 13 (was: 5)
Issue set to the milestone: Fedora 44
Issue tagged with: meta, task

**Metadata Update from @kparal**: - Custom field story_points adjusted to 13 (was: 5) - Issue set to the milestone: Fedora 44 - Issue tagged with: meta, task

kparal commented

2025-11-06 06:44:22 +00:00

Owner

I've split "migrate this repo" into #839 and converted this ticket into an "Epic" to "migrate all QA repos".

kparal commented

2025-11-13 10:55:37 +00:00

Owner

I started editing the main description and adding helpful links and notes into. Feel free to add more stuff to it that you find.

kparal commented

2025-11-26 15:44:21 +00:00

Owner

I've started working on dealing with some of the post-migration issues in #850.

kparal commented

2025-11-28 16:08:43 +00:00

Owner

The scripts are almost ready, see #850. We should be able to test out guinea-pig migrations to production next week.

kparal commented

2025-12-01 16:00:30 +00:00

Owner

How Forge labels work:

Org labels and repo labels are separate entities, they don't override each other. Even when named correctly, they are distinct, so you can have two "bug" labels assigned to a ticket, one of them being an org label and the other one a repo label.
The Forge migration script always creates all existing Pagure labels as repo labels, and then assigns them as repo labels only (even when org labels exist).
Using API, I can retrieve both kinds of labels using GET and distinguish them (label name is the same, but the url field can be used to distinguish them), but I can't seem to be able to determine what label is assigned using POST. I give just a label name in POST, and it assigns whatever label (org or label) exists. If both exist, it assigns both labels.

This means:

The Forge migrator can be used right away, it doesn't interact with org labels (which we don't have ready yet).
It should be possible to covert repo labels -> org labels later using our tooling, by reading an issue, assigning the same label name (it will also assign an org label of the same name), and once all tickets are done, undefining the repo label from Forge UI (that will delete it from all issues).
For story points conversion (see #850), we need to have org labels ready first.

How Forge labels work: 1. Org labels and repo labels are separate entities, they don't override each other. Even when named correctly, they are distinct, so you can have two "bug" labels assigned to a ticket, one of them being an org label and the other one a repo label. 2. The Forge migration script always creates all existing Pagure labels as repo labels, and then assigns them as repo labels only (even when org labels exist). 3. Using [API](https://forge.stg.fedoraproject.org/api/swagger), I can retrieve both kinds of labels using GET and distinguish them (label name is the same, but the url field can be used to distinguish them), but I can't seem to be able to determine what label is assigned using POST. I give just a label name in POST, and it assigns whatever label (org or label) exists. If both exist, it assigns both labels. This means: * The Forge migrator can be used right away, it doesn't interact with org labels (which we don't have ready yet). * It should be possible to covert repo labels -> org labels later using our tooling, by reading an issue, assigning the same label name (it will also assign an org label of the same name), and once all tickets are done, undefining the repo label from Forge UI (that will delete it from all issues). * For story points conversion (see #850), we need to have org labels ready first.

kparal commented

2025-12-02 13:52:43 +00:00

Owner

I've written a migration checklist (see this ticket description). I'll probably update all individual tickets with a reference to it.

I've also started a discussion on shared labels across the whole CLE, but since that discussion doesn't seem to be progressing a lot, I simply created the "Scrum" set on the Quality org level. Which means we can now migrate story points, because the points/* labels exist. We can figure out what to do with other labels later.

fedora-easy-karma has been migrated as the first project.

I've written a migration checklist (see this ticket description). I'll probably update all individual tickets with a reference to it. I've also started a discussion on shared labels across the whole CLE, but since that discussion doesn't seem to be progressing a lot, I simply created the "Scrum" set on the Quality org level. Which means we can now migrate story points, because the `points/*` labels exist. We can figure out what to do with other labels later. fedora-easy-karma has been migrated as the first project.

kparal commented

2025-12-04 11:27:19 +00:00

Owner

I found a serious problem in migration - issue attachments are not migrated properly. Let's freeze all migrations until it is resolved:
forge/forge#321

I found a serious problem in migration - issue attachments are not migrated properly. **Let's freeze all migrations until it is resolved:** https://forge.fedoraproject.org/forge/forge/issues/321

adamwill commented

2026-01-02 17:01:40 +00:00

Author

Owner

I fixed that one over the break, I believe. Please check. I did notice another issue while working on it - https://codeberg.org/forgejo/forgejo/issues/10472 - but I don't think that one really needs to block the migration.

I've also experimented with Actions on staging forgejo and more or less have it working, see https://forge.stg.fedoraproject.org/quality/fedfind/pulls/30 . So we should be able to handle migrations of repos with CI as well once we get a runner in prod, I've requested one.

I fixed that one over the break, I believe. Please check. I did notice another issue while working on it - https://codeberg.org/forgejo/forgejo/issues/10472 - but I don't think that one really needs to block the migration. I've also experimented with Actions on staging forgejo and more or less have it working, see https://forge.stg.fedoraproject.org/quality/fedfind/pulls/30 . So we should be able to handle migrations of repos with CI as well once we get a runner in prod, I've [requested one](https://forge.fedoraproject.org/forge/forge/issues/331).

kparal commented

2026-01-07 10:05:29 +00:00

Owner

I fixed that one over the break, I believe. Please check.

Great, it works. I've updated the ticket description. We can now proceed with the migrations.

I did notice another issue while working on it - https://codeberg.org/forgejo/forgejo/issues/10472 - but I don't think that one really needs to block the migration.

I noticed it as well, but decided to ignore it as insignificant.

So we should be able to handle migrations of repos with CI as well once we get a runner in prod, I've requested one.

Thanks!

> I fixed that one over the break, I believe. Please check. Great, it works. I've updated the ticket description. We can now proceed with the migrations. > I did notice another issue while working on it - https://codeberg.org/forgejo/forgejo/issues/10472 - but I don't think that one really needs to block the migration. I noticed it as well, but decided to ignore it as insignificant. > So we should be able to handle migrations of repos with CI as well once we get a runner in prod, I've requested one. Thanks!

adamwill commented

2026-01-10 02:56:26 +00:00

Author

Owner

Did a bunch of mine today. Left fedora_openqa because the migration script chokes on it and os-autoinst-distri-fedora because it's huge and scary. Will see if the migration script can cope with o-a-d-f at all tomorrow, I guess, and maybe do some of the shared ones like qa-misc and qa-stats. I also re-arranged the list to be grouped by migration status, which I think makes it easier to work with. Please move entries to the appropriate place when changing status.

kparal commented

2026-01-19 15:00:56 +00:00

Owner

We're down to 5 unmigrated Pagure repos. Two blocked by migration bugs, one to be migrated by Adam, one to be decided by Adam, and one that needs Forge support implemented in Blockerbugs.

kparal commented

2026-01-21 09:43:17 +00:00

Owner

I was wrong about forge/forge#281 , it's actually fixed. So we will wait until Forgejo 14.0 is deployed to production, and then we can migrate our main repo.

I was wrong about https://forge.fedoraproject.org/forge/forge/issues/281 , it's actually fixed. So we will wait until Forgejo 14.0 is deployed to production, and then we can migrate our main repo.

kparal added a new dependency

2026-01-22 11:36:00 +00:00

#839 Migrate fedora-qa to forgejo (without CI)

kparal added the

points

13

label

2026-01-22 11:42:31 +00:00

kparal commented

2026-01-22 12:25:55 +00:00

Owner

Main QA repo was migrated (yay!). However, we forgot about fedora_nightlies, I added it to the list.

Main QA repo was migrated (yay!). However, we forgot about _fedora_nightlies_, I added it to the list.

adamwill commented

2026-01-23 02:47:41 +00:00

Author

Owner

Thanks. Also, Ryan Lerch figured out the problem affecting fedora_openqa and os-autoinst-distri-fedora - both of them had both an issue 1 and a pull request 1 somehow (probably some kind of artifact from early Pagure releases). I wiped issue 1 for each of them, so now they can be successfully migrated, so I've marked them as non-blocked. I'll do them tomorrow.

❤️ 1

kevin commented

2026-01-23 19:39:36 +00:00

Possible things to add to your checklist:

setup matrix bot notifications ( https://docs.fedoraproject.org/en-US/forge-documentation/matrix_notifications/ )
setup templates ( https://docs.fedoraproject.org/en-US/forge-documentation/issue_pull_request_templates/ )
setup webhook to send fedora-messging messages ( https://webhook.fedoraproject.org/forgejo )

Just thought I would mention them.

Possible things to add to your checklist: * setup matrix bot notifications ( https://docs.fedoraproject.org/en-US/forge-documentation/matrix_notifications/ ) * setup templates ( https://docs.fedoraproject.org/en-US/forge-documentation/issue_pull_request_templates/ ) * setup webhook to send fedora-messging messages ( https://webhook.fedoraproject.org/forgejo ) Just thought I would mention them.

adamwill commented

2026-01-23 23:49:08 +00:00

Author

Owner

I went through the taskotron organization and found two repos that are still relevant and which we'll need to account for: resultsdb_api and resultsdb_frontend.

I went through the taskotron organization and found two repos that are still relevant and which we'll need to account for: [resultsdb_api](https://pagure.io/taskotron/resultsdb_api/issue/16) and [resultsdb_frontend](https://pagure.io/taskotron/resultsdb_frontend/issue/24).

adamwill added this to the Sprint 1 project

2026-01-27 07:25:46 +00:00

adamwill commented

2026-01-27 07:26:27 +00:00

Author

Owner

Should we close this out now? It's more or less done and I'm not sure there's value in keeping it open until we're done with blocker-review, that might take a while.

adamwill referenced this issue

2026-01-27 17:31:58 +00:00

Forgejo migration: outlier repos #863

adamwill commented

2026-01-27 17:32:15 +00:00

Author

Owner

Created #863 as a follow-up ticket for the stragglers, closing this one. Good job everyone!

Created https://forge.fedoraproject.org/quality/tickets/issues/863 as a follow-up ticket for the stragglers, closing this one. Good job everyone!

adamwill closed this issue

2026-01-27 17:32:15 +00:00

adamwill referenced this issue