perl-File-Find-Object epel10 branch creation only partially succeeded #12162
Labels
No labels
announcement
authentication
automate
aws
backlog
blocked
bodhi
ci
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Initiative Worthy
Closed As
Insufficient data
Closed As
Invalid
Closed As
Spam
Closed As
Upstream
Closed As/Will Not
Can Not fix
cloud
communishift
copr
database
deprecated
dev
discourse
dns
downloads
easyfix
epel
factory2
firmitas
gitlab
greenwave
hardware
help wanted
high-gain
high-trouble
iad2
koji
koschei
lists
low-gain
low-trouble
mbs
medium-gain
medium-trouble
mini-initiative
mirrorlists
monitoring
Needs investigation
notifier
odcs
OpenShift
ops
OSBS
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
rdu-cc
release-monitoring
releng
repoSpanner
request-for-resources
s390x
security
SMTP
src.fp.o
staging
taiga
unfreeze
waiverdb
websites-general
wiki
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Infrastructure/fedora-infrastructure#12162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I requested an epel10 branch of perl-File-Find-Object this morning, but the request failed (https://pagure.io/releng/fedora-scm-requests/issue/66267) with Status: 500
Nevertheless, the branch was actually created and I can push to it but the build fails with the error BuildError: package perl-File-Find-Object not in list for tag epel10.0-testing-candidate:
This is the same as what happened for me with perl-Sereal yesterday (https://pagure.io/fedora-infrastructure/issue/12159). I was eventually able to build that several hours later in the day but I don't know whether that was because somebody actually did something to fix it, or a sync process happened that fixed it in the background.
Still failing at the moment so if there's a background process fixing this, it doesn't seem to run very often.
The error means that the https://src.fedoraproject.org/ returned 500 when calling the branch creation API.
The script that is creating the branch is not doing anything with koji, so this must be caused somewhere else then during creation of the branch. My assumption would be that the pagure API is enabling the koji for the package and this failed.
Let me check if that is true.
Metadata Update from @zlopez:
So the pagure API code doesn't touch koji at all, just trying to create the branch in pagure. So the koji enablement must happen somewhere else.
@carlwgeorge I think something is not correctly setup for epel10 yet, or is this expected behavior?
I don't think it's expected behavior because I've done dozens of epel10 branch requests over the last couple of weeks and only 2 have failed like this.
After the branch is created, is there a message sent out? I wonder if that message perhaps doesn't get sent out and then something else doesn't see the message and hence doesn't update koji?
The message is sent, you can see all the latest messages in datagrepper
EDIT: And here is the message about creation of the branch you requested.
The process that syncs projects/branches/ownership to koji is the koji_sync_listener service ( fm-consumer@koji_sync_listener.service ) running on bodhi-backend01.
It should be listening to those messages and acting on them. I don't know why it did not in this case.
It also runs once a day a 'full sync' where it checks all packages and syncs ownership/etc to koji.
There goes my theory then. No idea what's going wrong, though the traceback in the branch request does correlate with the koji issue manifesting.
Build still failing at the moment.
Ah, so does the once-a-day run take place sometime around 1900UTC? That could explain why my perl-Sereal build eventually worked yesterday.
Indeed the original error
toddlers.exceptions.pagure_error.PagureError
is because of the status code returned by pagure. I've seen it happen occasionally, but as of yet no one has done a deep dive investigation to figure out why. With the impending replacement of pagure I'm not entirely sure spending cycles on a rare intermittent error is worth the effort.Allowing the package in koji is done in two ways:
I believe the cron job would have picked this up and fixed it, but I went ahead and manually added the package to the tag allowlist to unblock you.
Thanks, build succeeded now. What time zone does that cron job run in? It'll be useful to know when to resubmit builds if this crops up again, which is quite likely given that I'm working through a lot of the perl stack for EPEL-10 at the moment. It'll save me having to keep re-submitting until it works.
It's UTC. All infrastructure machines are on UTC.
I'm a bit puzzled how this message wasn't processed, but I am not sure how to debug it any further. I looked for that message in the logs for the sync listener and didn't see it... ;(
I'm not sure how my perl-Sereal build from yesterday (https://koji.fedoraproject.org/koji/buildinfo?buildID=2539922) started working now. The successful build started at 1655 after several failures at various points earlier in the day. However, the cron job seems to be set to run at 0415 so it seems unlikely that that cron job is what fixed things.
Saw a different error today (https://pagure.io/releng/fedora-scm-requests/issue/66371):
Don't know if this is blocking a build or not because there is another issue affecting the epel10 buildroot today (https://pagure.io/releng/issue/12305), which I'm hitting for all epel10 builds. It doesn't look promising though:
This error just means that the script couldn't close the ticket as processed, so it doesn't affect anything.
Well that's what I'd have thought too but the ticket did in fact get closed and perl-Cpanel-JSON-XS doesn't seem to be in the list for epel10.0-testing-candidate.
Yeah, It seems that the ticket was closed and the error happened in the code after closing the ticket.
Not unexpectedly, my
perl-Cpanel-JSON-XS
build (branch request ticket had error this morning) failed:I'll try again later/tomorrow, by which time the cron job or whatever should have fixed the issue.
Either the cron tab takes a very long time to run or it has not resolved the issue:
And at last, I was able to build perl-Cpanel-JSON-XS. No idea what happened to change things.
Today's example:
perl-Module-Find
No indication that anything went wrong in the branch request (https://pagure.io/releng/fedora-scm-requests/issue/66471).
Now managed to build
perl-Module-Find
. Wasn't able to a couple of hours ago. Don't know what changed.Are you still seeing this?
Seen it once since perl-Module-Find and it resolved itself after a day or so (https://pagure.io/releng/fedora-scm-requests/issue/67247).
I've done the bulk of my packages in the perl stack now so my request frequency is much lower in the last couple of weeks.
ok, lets close this... if you see it again, can you please re-open and we can try and track it down while it's fresh.
Metadata Update from @kevin: