Migration of fedora-scm-requests to Forgejo

jnsamyak commented

2025-12-01 12:02:24 +00:00

Owner

Summary

The fedora-scm-requests repository is a critical component of the Fedora workflow, used extensively across package maintainers, Release Engineering, and Infra to handle requests related to SCM operations (package creation, branch requests, ACL changes, orphaning, retirements, etc.).

As part of the RelEng sub-repository migration plan for Sprint 5, we are migrating this repository from Pagure to Forgejo to align with the Forgejo-based workflow used across the Fedora Infrastructure.

This work follows the two-week Sprint schedule:

Week 1: Investigation and dependency assessment

Week 2: Implementation and validation

Deadline: Two weeks from today (when picked up).

**Summary** The fedora-scm-requests repository is a critical component of the Fedora workflow, used extensively across package maintainers, Release Engineering, and Infra to handle requests related to SCM operations (package creation, branch requests, ACL changes, orphaning, retirements, etc.). As part of the RelEng sub-repository migration plan for Sprint 5, we are migrating this repository from Pagure to Forgejo to align with the Forgejo-based workflow used across the Fedora Infrastructure. This work follows the two-week Sprint schedule: Week 1: Investigation and dependency assessment Week 2: Implementation and validation Deadline: Two weeks from today (when picked up).

👍 1

gotmax23 commented

2025-12-04 02:49:44 +00:00

Member

Is it really worth doing this now? The scm request toddler code will have to be changed again when distgit moves to Forgejo, and also it'd nice to wait to do this until then so the tracker can be hosted on src.fp.o instead of on the main forge instance.

jnsamyak added the

labels

2025-12-09 09:04:54 +00:00

humaton commented

2025-12-09 09:11:56 +00:00

Owner

I think @gotmax23 has a valid point. Releng should not move the repository yet. However, it makes sense to proceed with investigating and identifying all the changes that will be needed across the ecosystem, for example, in toddlers and fedpkg.

The person doing the investigation should also consider Forgejo’s newer functionality. Leveraging Forgejo Actions could allow releng to keep both the tracker and the automation definitions in a single repository.

I think @gotmax23 has a valid point. Releng should not move the repository yet. However, it makes sense to proceed with investigating and identifying all the changes that will be needed across the ecosystem, for example, in toddlers and fedpkg. The person doing the investigation should also consider Forgejo’s newer functionality. Leveraging Forgejo Actions could allow releng to keep both the tracker and the automation definitions in a single repository.

amedvede commented

2026-01-07 15:19:27 +00:00

Owner

agree, lets discuss it at the meeting. I would say it will be better process in a two-step way:

create empty repo on forge
add functionality for fedpkg to open tickets ion both pagure and forge
test how toddler automation works with messages comming from forge
migrate repos and remove ticket creation for pagure in fedpkg

agree, lets discuss it at the meeting. I would say it will be better process in a two-step way: 1. create empty repo on forge 2. add functionality for `fedpkg` to open tickets ion both pagure and forge 3. test how `toddler` automation works with messages comming from forge 4. migrate repos and remove ticket creation for `pagure` in `fedpkg`

churchyard commented

2026-03-25 09:53:55 +00:00

Member

Will pagure.io live long enough to keep using it for this until the distgit is on forgejo?

zlopez commented

2026-03-25 10:54:09 +00:00

Member

@churchyard No, see https://communityblog.fedoraproject.org/the-forge-is-our-new-home/. The distgit will start the migration after pagure.io is migrated and archived.

churchyard commented

2026-03-25 10:59:24 +00:00

Member

That's what I thought. Hence, the proposed solution to this won't work.

humaton commented

2026-03-26 09:40:52 +00:00

Owner

I think one of the possible approaches is to just drop this functionality from the toddlers and re-implement it like this:

Update fedpkg to create tickets in the new forge.
Create forgejo on_issues action that will validate the request same as toddler does now. It might be possible to reus ethe python code with some changes and run it in the action.
If necessary post a comment on the ticket requesting info from releng or the user.
Re-run the action if necessary
Profit

I think one of the possible approaches is to just drop this functionality from the toddlers and re-implement it like this: 1. Update fedpkg to create tickets in the new forge. 2. Create forgejo on_issues [action](https://forgejo.org/docs/latest/user/actions/reference/#onissues) that will validate the request same as toddler does now. It might be possible to reus ethe python code with some changes and run it in the action. 3. If necessary post a comment on the ticket requesting info from releng or the user. 4. Re-run the action if necessary 5. **Profit**

👍 1

humaton added a new dependency

2026-05-28 09:27:05 +00:00

#13369 [fedora-scm-requests] - Update fedpkg

humaton added a new dependency

2026-05-28 09:27:25 +00:00

#13368 [fedora-scm-requests] - move the repository

humaton added

and removed

labels

2026-05-28 09:27:39 +00:00

humaton added a new dependency

2026-05-28 09:31:49 +00:00

#13370 [fedora-scm-requests] - Migrate scm-request related stuff in toddlers to support the new forge

humaton removed the

points

13

label

2026-05-28 09:32:04 +00:00

kevin referenced this issue

2026-06-18 22:55:27 +00:00

[fedora-scm-requests] - move the repository #13368

patrikp added a new dependency

2026-07-07 07:07:36 +00:00

#13414 [fedora-scm-requests] Archive the repository on Pagure and the older one to forge as well

jnsamyak commented

2026-07-14 16:54:26 +00:00

Author

Owner

Update here:

I worked on making toddler changes for scm-requests: apps/toddlers#429;

But this is blocked by fedpkg changes (on @patrikp), and the ticket we closed for moving the repository has to be opened again, because currently it doesn't make sense to have a repository that is not synced properly with the latest updates happening at pagure. So, I'll reopen that ticket, also as part of processing ticket two; things need to be configured for that repository.

Labels: close issues with a comment and a label; these names must match toddlers config (label_invalid / label_processed). Defaults are the strings above.

I remember creating a releng-bot for compose-tracker / compose-tracker-issues. I think we can similarly create a new one or reuse it as an account for commenting, closing, and opening the issue here as well?

And, another crucial bit, need to hook Webhook → fedora-messaging (W2FM), any recommendation for making it repo/or org level?

Lastly, to add these configurations (tokens et al) to Ansible private (I think that was the place, but I might need to check again (jog up my last brain cell :)

But bottom line being once we have supported fedpkg changes in, for toddler changes, this is a mental roadmap that I used: #13370 (comment)

CC: @patrikp @humaton @kevin @zlopez

Update here: I worked on making toddler changes for scm-requests: https://forge.fedoraproject.org/apps/toddlers/pulls/429; But this is blocked by fedpkg changes (on @patrikp), and the ticket we closed for moving the repository has to be opened again, because currently it doesn't make sense to have a repository that is not synced properly with the latest updates happening at pagure. So, I'll reopen that ticket, also as part of processing ticket two; things need to be configured for that repository. Labels: close issues with a comment and a label; these names must match toddlers config (`label_invalid` / `label_processed`). Defaults are the strings above. I remember creating a `releng-bot` for compose-tracker / compose-tracker-issues. I think we can similarly create a new one or reuse it as an account for commenting, closing, and opening the issue here as well? And, another crucial bit, need to hook Webhook → fedora-messaging (W2FM), any recommendation for making it repo/or org level? Lastly, to add these configurations (tokens et al) to Ansible private (I think that was the place, but I might need to check again (jog up my last brain cell :) But bottom line being once we have supported fedpkg changes in, for toddler changes, this is a mental roadmap that I used: https://forge.fedoraproject.org/releng/tickets/issues/13370#issuecomment-1062204 CC: @patrikp @humaton @kevin @zlopez

kevin commented

2026-07-14 21:13:11 +00:00

Owner

@jnsamyak wrote in #13108 (comment):

Update here:

I worked on making toddler changes for scm-requests: apps/toddlers#429;

But this is blocked by fedpkg changes (on @patrikp), and the ticket we closed for moving the repository has to be opened again, because currently it doesn't make sense to have a repository that is not synced properly with the latest updates happening at pagure. So, I'll reopen that ticket, also as part of processing ticket two; things need to be configured for that repository.

It's going to be tricky to copy this repo over and switch to it, since users are somewhat out of our control... but we can do a flag day.

Labels: close issues with a comment and a label; these names must match toddlers config (label_invalid / label_processed). Defaults are the strings above.

I remember creating a releng-bot for compose-tracker / compose-tracker-issues. I think we can similarly create a new one or reuse it as an account for commenting, closing, and opening the issue here as well?

Yeah.

And, another crucial bit, need to hook Webhook → fedora-messaging (W2FM), any recommendation for making it repo/or org level?

Docs are at: https://docs.fedoraproject.org/en-US/forge-documentation/webhook_to_fedora_messaging/
any org admin can set it up for an org.

I would argue we should just set it automatically for all non private repos
( forge/forge#569 )

Lastly, to add these configurations (tokens et al) to Ansible private (I think that was the place, but I might need to check again (jog up my last brain cell :)

But bottom line being once we have supported fedpkg changes in, for toddler changes, this is a mental roadmap that I used: #13370 (comment)

CC: @patrikp @humaton @kevin @zlopez

Once fedpkg changes are in, new fedpkg packages need built for all supported releases.
Then they need to be pushed stable.
Then maintainers need to start using them. ;)

But yeah, once they are available we can point people to update if they can't request the old way.

@jnsamyak wrote in https://forge.fedoraproject.org/releng/tickets/issues/13108#issuecomment-1062470: > Update here: > > I worked on making toddler changes for scm-requests: apps/toddlers#429; > > But this is blocked by fedpkg changes (on @patrikp), and the ticket we closed for moving the repository has to be opened again, because currently it doesn't make sense to have a repository that is not synced properly with the latest updates happening at pagure. So, I'll reopen that ticket, also as part of processing ticket two; things need to be configured for that repository. It's going to be tricky to copy this repo over and switch to it, since users are somewhat out of our control... but we can do a flag day. > Labels: close issues with a comment and a label; these names must match toddlers config (`label_invalid` / `label_processed`). Defaults are the strings above. > > I remember creating a `releng-bot` for compose-tracker / compose-tracker-issues. I think we can similarly create a new one or reuse it as an account for commenting, closing, and opening the issue here as well? Yeah. > And, another crucial bit, need to hook Webhook → fedora-messaging (W2FM), any recommendation for making it repo/or org level? Docs are at: https://docs.fedoraproject.org/en-US/forge-documentation/webhook_to_fedora_messaging/ any org admin can set it up for an org. I would argue we should just set it automatically for all non private repos ( https://forge.fedoraproject.org/forge/forge/issues/569 ) > Lastly, to add these configurations (tokens et al) to Ansible private (I think that was the place, but I might need to check again (jog up my last brain cell :) > > But bottom line being once we have supported fedpkg changes in, for toddler changes, this is a mental roadmap that I used: #13370 (comment) > > CC: @patrikp @humaton @kevin @zlopez Once fedpkg changes are in, new fedpkg packages need built for all supported releases. Then they need to be pushed stable. Then maintainers need to start using them. ;) But yeah, once they are available we can point people to update if they can't request the old way.

patrikp commented

2026-07-30 08:47:16 +00:00

Member

Once fedpkg changes are in, new fedpkg packages need built for all supported releases.
Then they need to be pushed stable.
Then maintainers need to start using them. ;)

But yeah, once they are available we can point people to update if they can't request the old way.

fedpkg changes have been merged [1] and the maintainer is currently working on the release and building the packages.

[1] packaging/fedpkg#636

> Once fedpkg changes are in, new fedpkg packages need built for all supported releases. > Then they need to be pushed stable. > Then maintainers need to start using them. ;) > But yeah, once they are available we can point people to update if they can't request the old way. fedpkg changes have been merged [1] and the maintainer is currently working on the release and building the packages. [1] https://forge.fedoraproject.org/packaging/fedpkg/pulls/636

jnsamyak commented

2026-08-04 18:20:08 +00:00

Author

Owner

`fedora-scm-requests` Migration Checklist!

Main ticket: releng/tickets#13108 (see linked sub-tickets for per-step tracking)
Toddlers rollout PR: apps/toddlers#429

Migration date: Wed Aug 05, 2026 at 14 UTC

Legend: [ ] not started · [~] in progress · [x] done · ⚠️ needs infra/sysadmin-main privileges

Phase 0: T-minus (days before migration day)

0.1 Get the fedpkg PR in.
0.2 Get the fedpkg Toddlers PR in.

Phase 1: Pre-move announcement ("it's moving, upgrade fedpkg")

1.1 Confirm the minimum fedpkg/fedpkg-* are there, (Update: they are currently unpushed)
1.2 Send the pre-move announcement to devel-announce@lists.fedoraproject.org Cover:
- What's moving (fedora-scm-requests ticket queue) and when
- Action required: sudo dnf upgrade fedpkg 'fedpkg-*' before the cutover if you plan to file new-package/new-branch requests after that date
- That old tickets on pagure.io remain visible (read-only) after cutover, new ones must go through new forge under releng org
- Link to the tracking ticket (13108) for questions/status
1.3 Post a short heads-up in #fedora-releng and #fedora-admin Matrix channels.
1.4 Directly ping (Matrix/email) the frequent filers, doing 1.3 will help anyway, but reaching out to some will help ease the testing or be prepared to test out with some sample packages, ask @kevin etc?

Phase 2: Stable-release testing-updates push + rawhide builds

Do this ahead of/alongside cutover so the release pipeline itself isn't mid-compose when tooling changes underneath it.

Push the fedpkg changes (stable and rawhide ones).
⚠️ The actual stable/testing push is usually kicked via the standing RelEng push cron/Bodhi masher run but in our case we unpushed those changes so we can just push it back to testing through UI. Confirm whether this needs a manual bodhi-push invocation or is already scheduled; don't duplicate the automated masher run.

Phase 3: Create the Forge repo (again sync it, so we have the top of the changes with us ready?)

3.1 Make sure the pagure repo is readme already, we did in the earlier phases, make sure it is cleanly written that: "Tickets here are processed automatically by toddlers. If processing fails, open a ticket at releng/tickets. Comments here will not be seen.""
3.2 Create the releng/fedora-scm-requests repo on Forge by migrating it through pagure exporter.
3.3 Grant the bot/service account (releng-scm-bot or equivalent) collaborator access with issue read/write. I think this needs to be created in ansible private repo right @kevin? Also we need to create a webhook fo rmessage bus right, I think we missed this discussion yesterday.
3.4** Verify repo settings match policy (issues-only, no PRs, no wiki) and that it shows up under the releng org.

Phase 4: Merge & roll out the new toddlers code

4.1 Merge PR #429 for main, staging, and production.

4.2 Staging rollout (os-control01.stg) deploy first, verify, then production:

oc project toddlers
oc get deploy
# roll out the new image/config (adjust to actual deploy/ImageStream name)
oc rollout restart deployment/toddlers
oc rollout status deployment/toddlers --watch

I think we can do this using ansible playbook too:

ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml --limit staging

Test it out.

4.3 Production rollout (os-control01) made sure staging works?:

oc project toddlers
oc get deploy
# roll out the new image/config (adjust to actual deploy/ImageStream name)
oc rollout restart deployment/toddlers
oc rollout status deployment/toddlers --watch

I think we can do this using ansible playbook too:

ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml

Test it out.

4.4 Confirm toddlers' production logs show it polling/listening on the new repo with no auth errors:

oc logs deployment/toddlers -n toddlers-production --since=10m | grep -i -E "error|forbidden|401"

Phase 5: End-to-end test with real volunteers or us

5.1 Give the go-ahead to the 2–3 volunteers from Phase 2 to file real requests:

fedpkg request-repo <new-package-name>
fedpkg request-branch <existing-package> f44

5.2 Confirm each ticket lands in releng/fedora-scm-requests, gets picked up by toddlers, and the resulting dist-git repo/branch actually appears in rpms/:

curl -s https://forge.fedoraproject.org/api/v1/repos/rpms/<new-package-name> | jq '.name, .created_at'
git ls-remote https://forge.fedoraproject.org/rpms/<new-package-name>.git

5.3 If anything fails, pause here, discuss instinct is to fix the code on the go. Reach out to folks.

Phase 6: Post-move announcement & Monitoring

6.1 Send the "it's migrated" announcement to the same lists/channels as Phase 1 (devel-announce@, #fedora-releng, #fedora-admin). Include:
- New location: forge.fedoraproject.org/releng/fedora-scm-requests
- Confirmation pagure.io copy is now read-only/archived
- Reminder: fedpkg request-repo/request-branch now target Forge automatically if fedpkg is up to date no user-facing command change expected, just backend
- Where to report problems (13108) this ticket itself
6.2 Update any docs/wiki pages that still link to pagure.io/releng/fedora-scm-requests (Fedora wiki, Join docs, packager onboarding docs) to point at the Forge URL.
6.3 Close out sub-tickets under 13108 as each phase completes; leave 13108 itself open through the monitoring window.
6.4 After ~1 week of clean operation, note in 13108 that monitoring is complete and close the ticket.

## `fedora-scm-requests` Migration Checklist! **Main ticket:** [releng/tickets#13108](https://forge.fedoraproject.org/releng/tickets/issues/13108) (see linked sub-tickets for per-step tracking) **Toddlers rollout PR:** [apps/toddlers#429](https://forge.fedoraproject.org/apps/toddlers/pulls/429) Migration date: Wed Aug 05, 2026 at 14 UTC Legend: `[ ]` not started · `[~]` in progress · `[x]` done · ⚠️ needs infra/sysadmin-main privileges --- ## Phase 0: T-minus (days before migration day) - [x] **0.1 Get the fedpkg PR in.** - [x] **0.2 Get the fedpkg Toddlers PR in.** ## Phase 1: Pre-move announcement ("it's moving, upgrade fedpkg") - [x] **1.1** Confirm the minimum `fedpkg`/`fedpkg-*` are there, (Update: they are currently unpushed) - [x] **1.2** Send the pre-move announcement to `devel-announce@lists.fedoraproject.org` Cover: - What's moving (`fedora-scm-requests` ticket queue) and when - Action required: `sudo dnf upgrade fedpkg 'fedpkg-*'` before the cutover if you plan to file new-package/new-branch requests after that date - That old tickets on pagure.io remain visible (read-only) after cutover, new ones must go through new forge under releng org - Link to the tracking ticket (13108) for questions/status - [x] **1.3** Post a short heads-up in `#fedora-releng` and `#fedora-admin` Matrix channels. - [x] **1.4** Directly ping (Matrix/email) the frequent filers, doing 1.3 will help anyway, but reaching out to some will help ease the testing or be prepared to test out with some sample packages, ask @kevin etc? --- ## Phase 2: Stable-release testing-updates push + rawhide builds Do this ahead of/alongside cutover so the release pipeline itself isn't mid-compose when tooling changes underneath it. - [x] Push the fedpkg changes (stable and rawhide ones). ⚠️ The actual stable/testing push is usually kicked via the standing RelEng push cron/Bodhi masher run but in our case we unpushed those changes so we can just push it back to testing through UI. Confirm whether this needs a manual `bodhi-push` invocation or is already scheduled; don't duplicate the automated masher run. --- ## Phase 3: Create the Forge repo (again sync it, so we have the top of the changes with us ready?) - [ ] **3.1** Make sure the pagure repo is readme already, we did in the earlier phases, make sure it is cleanly written that: *"Tickets here are processed automatically by toddlers. If processing fails, open a ticket at releng/tickets. Comments here will not be seen."*" - [ ] **3.2** Create the `releng/fedora-scm-requests` repo on Forge by migrating it through pagure exporter. - [ ] **3.3** Grant the bot/service account (`releng-scm-bot` or equivalent) collaborator access with issue read/write. I think this needs to be created in ansible private repo right @kevin? Also we need to create a webhook fo rmessage bus right, I think we missed this discussion yesterday. - [ ] 3.4** Verify repo settings match policy (issues-only, no PRs, no wiki) and that it shows up under the `releng` org. --- ## Phase 4: Merge & roll out the new toddlers code - [ ] **4.1** Merge PR #429 for main, staging, and production. - [ ] **4.2 Staging rollout** (os-control01.stg) deploy first, verify, *then* production: ```bash oc project toddlers oc get deploy # roll out the new image/config (adjust to actual deploy/ImageStream name) oc rollout restart deployment/toddlers oc rollout status deployment/toddlers --watch ``` I think we can do this using ansible playbook too: ```bash ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml --limit staging ``` Test it out. - [ ] **4.3 Production rollout** (os-control01) made sure staging works?: ```bash oc project toddlers oc get deploy # roll out the new image/config (adjust to actual deploy/ImageStream name) oc rollout restart deployment/toddlers oc rollout status deployment/toddlers --watch ``` I think we can do this using ansible playbook too: ```bash ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml ``` Test it out. - [ ] **4.4** Confirm toddlers' production logs show it polling/listening on the new repo with no auth errors: ```bash oc logs deployment/toddlers -n toddlers-production --since=10m | grep -i -E "error|forbidden|401" ``` --- ## Phase 5: End-to-end test with real volunteers or us - [ ] **5.1** Give the go-ahead to the 2–3 volunteers from Phase 2 to file real requests: ```bash fedpkg request-repo <new-package-name> fedpkg request-branch <existing-package> f44 ``` - [ ] **5.2** Confirm each ticket lands in `releng/fedora-scm-requests`, gets picked up by toddlers, and the resulting dist-git repo/branch actually appears in `rpms/`: ```bash curl -s https://forge.fedoraproject.org/api/v1/repos/rpms/<new-package-name> | jq '.name, .created_at' git ls-remote https://forge.fedoraproject.org/rpms/<new-package-name>.git ``` - [ ] **5.3** If anything fails, pause here, discuss instinct is to fix the code on the go. Reach out to folks. --- ## Phase 6: Post-move announcement & Monitoring - [ ] **6.1** Send the "it's migrated" announcement to the same lists/channels as Phase 1 (`devel-announce@`, `#fedora-releng`, `#fedora-admin`). Include: - New location: `forge.fedoraproject.org/releng/fedora-scm-requests` - Confirmation pagure.io copy is now read-only/archived - Reminder: `fedpkg request-repo`/`request-branch` now target Forge automatically if `fedpkg` is up to date no user-facing command change expected, just backend - Where to report problems (13108) this ticket itself - [ ] **6.2** Update any docs/wiki pages that still link to `pagure.io/releng/fedora-scm-requests` (Fedora wiki, Join docs, packager onboarding docs) to point at the Forge URL. - [ ] **6.3** Close out sub-tickets under 13108 as each phase completes; leave 13108 itself open through the monitoring window. - [ ] **6.4** After ~1 week of clean operation, note in 13108 that monitoring is complete and close the ticket. ---

kevin commented

2026-08-04 18:52:21 +00:00

Owner

Some comments:

1.2 Send the pre-move announcement to devel-announce@lists.fedoraproject.org Cover:

Is this not the one we already sent? I don't think we need another one...

Phase 2: Stable-release testing-updates push + rawhide builds

Well, first we need to request testing on those updates and do a compose to push them to testing
We could later (after they are confirmed to work, have karma) do a special stable push for them, but it might be that the regular cron would be fine. I think as long as they are in testing thats ok.

For rawhide we need to:

make sidetag
build rpkg in it
wait for it to be in the sidetag buildroot
build fedpkg
submit sidetag as a update

3.3 Grant the bot/service account (releng-scm-bot or equivalent) collaborator access with issue read/write. I think this needs to be created in ansible private repo right @kevin? Also we need to create a webhook fo rmessage bus right, I think we missed this discussion yesterday.

I think we can use the 'releng-bot' user that is already a member of releng?
And yes a webhook to fedora-messaging is wanted. (In fact I would say add this at the releng org level).

I think we can do this using ansible playbook too:

ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml --limit staging

You want a '-t all,build,deploy' there to make it apply and build and then deploy.

On the 'it's done' announcement, we may want to mention that the updated fedpkg may be in updates-testing, so install from there if needed.

Some comments: > 1.2 Send the pre-move announcement to devel-announce@lists.fedoraproject.org Cover: Is this not the one we already sent? I don't think we need another one... > Phase 2: Stable-release testing-updates push + rawhide builds Well, first we need to request _testing_ on those updates and do a compose to push them to _testing_ We could later (after they are confirmed to work, have karma) do a special stable push for them, but it might be that the regular cron would be fine. I think as long as they are in testing thats ok. For rawhide we need to: - make sidetag - build rpkg in it - wait for it to be in the sidetag buildroot - build fedpkg - submit sidetag as a update > 3.3 Grant the bot/service account (releng-scm-bot or equivalent) collaborator access with issue read/write. I think this needs to be created in ansible private repo right @kevin? Also we need to create a webhook fo rmessage bus right, I think we missed this discussion yesterday. I think we can use the 'releng-bot' user that is already a member of releng? And yes a webhook to fedora-messaging is wanted. (In fact I would say add this at the releng org level). > I think we can do this using ansible playbook too: > > ansible-playbook -i inventory/staging playbooks/openshift-apps/toddlers.yml --limit staging You want a '-t all,build,deploy' there to make it apply and build and then deploy. On the 'it's done' announcement, we may want to mention that the updated fedpkg may be in updates-testing, so install from there if needed.

~~releng-bot referenced this issue 2026-08-05 18:46:31 +00:00~~

[fedora-scm-requests] - Update fedpkg #13369

jnsamyak referenced this issue

2026-08-05 18:47:24 +00:00

[fedora-scm-requests] - Update fedpkg #13369

jnsamyak referenced this issue

2026-08-05 18:48:29 +00:00

[fedora-scm-requests] - Migrate scm-request related stuff in toddlers to support the new forge #13370

jnsamyak commented

2026-08-05 18:51:06 +00:00

Author

Owner

Migration is successful, we will keep this ticket open for this week for any questions and issues.

jnsamyak referenced this issue

2026-08-05 18:53:02 +00:00

[fedora-scm-requests] Archive the repository on Pagure and the older one to forge as well #13414

jnsamyak added

and removed

labels

2026-08-05 18:56:57 +00:00

jnsamyak referenced this issue

2026-08-06 04:15:36 +00:00

[toddlers_migrate_scm_request] Enhance the feature to list of feature to get pointed out from a single source of team #13455

eseyman commented

2026-08-06 09:35:59 +00:00

One thing I haven't seen addressed anywhere is what repositories and permissions a token dedicated to SCM requests must have. I'm guessing access to 'releng/scm-requests' and 'Read/Write issues' would suffice but I'm unable to choose 'releng/scm-requests' in the repositories so I had to go with 'Public only'

kevin commented

2026-08-06 17:24:37 +00:00

Owner

Well, take a look at 'fedpkg request-branch --help':

"Before the operation, you need to generate a Forgejo API token at:
https://forge.fedoraproject.org/user/settings/applications

ACL required:
    "write:issue"

Update your token with the following command:
fedpkg set-forgejo-token

Command saves token to fedpkg config file:
~/.config/rpkg/fedpkg.conf"

But yeah, it could be scoped to releng/fedora-scm-requests repo only.
Note that it's "fedora-scm-requests" not "scm-requests"

Well, take a look at 'fedpkg request-branch --help': "Before the operation, you need to generate a Forgejo API token at: https://forge.fedoraproject.org/user/settings/applications ACL required: "write:issue" Update your token with the following command: fedpkg set-forgejo-token Command saves token to fedpkg config file: ~/.config/rpkg/fedpkg.conf" But yeah, it could be scoped to releng/fedora-scm-requests repo only. Note that it's "fedora-scm-requests" not "scm-requests"

eseyman commented

2026-08-07 13:53:28 +00:00

Well, take a look at 'fedpkg request-branch --help':

Indeed. My bad.

Note that it's "fedora-scm-requests" not "scm-requests"

I'm unable to select 'releng/fedora-scm-requests' in the "Available repositories" section. It seems I can only choose the Server SIG repositories and my forks.

> Well, take a look at 'fedpkg request-branch --help': Indeed. My bad. > Note that it's "fedora-scm-requests" not "scm-requests" I'm unable to select 'releng/fedora-scm-requests' in the "Available repositories" section. It seems I can only choose the Server SIG repositories and my forks.

kevin commented

2026-08-07 17:54:16 +00:00

Owner

:( Sounds like a forge bug/limitation... looks like it was just implemented that way without thinking about tickets:

https://codeberg.org/forgejo/forgejo/pulls/11696#issuecomment-11736297

:( Sounds like a forge bug/limitation... looks like it was just implemented that way without thinking about tickets: https://codeberg.org/forgejo/forgejo/pulls/11696#issuecomment-11736297

mavit commented

2026-08-10 12:03:01 +00:00

https://status.fedoraproject.org/resolved.html#:~:text=%20Migration%20of%20fedora-scm-requests%20from%20Pagure%20to%20Forgejo links to this ticket, and says:

Please ensure you have updated fedpkg before filing new requests.

It would be helpful if this said "to version 1.48", especially since that version hasn't hit stable yet.

https://status.fedoraproject.org/resolved.html#:~:text=%20Migration%20of%20fedora-scm-requests%20from%20Pagure%20to%20Forgejo links to this ticket, and says: > Please ensure you have updated fedpkg before filing new requests. It would be helpful if this said "to version 1.48", especially since that version hasn't hit stable yet.

Rows
Columns

Migration of fedora-scm-requests to Forgejo #13108

fedora-scm-requests Migration Checklist!

Phase 0: T-minus (days before migration day)

Phase 1: Pre-move announcement ("it's moving, upgrade fedpkg")

Phase 2: Stable-release testing-updates push + rawhide builds

Phase 3: Create the Forge repo (again sync it, so we have the top of the changes with us ready?)

Phase 4: Merge & roll out the new toddlers code

Phase 5: End-to-end test with real volunteers or us

Phase 6: Post-move announcement & Monitoring

`fedora-scm-requests` Migration Checklist!