search

fedora-copr / copr

RPM build system - upstream for https://copr.fedorainfracloud.org/
115 stars 58 forks source link

The Custom method should have `fedora-stable-x86_64` option #3409

Open praiskup opened 2 weeks ago

praiskup commented 2 weeks ago

The fedora-latest-x86_64 isn't optimal, the failure probability is relatively high, e.g., here:

Start: installing minimal buildroot with dnf5
Updating and loading repositories:
 updates                                100% |   1.5 KiB/s |   7.5 KiB |  00m05s
 fedora                                 100% |   5.4 MiB/s |  32.7 MiB |  00m06s
 Additional repo copr_packit_packit_sta 100% | 147.0   B/s |   1.3 KiB |  00m09s
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xFailed to download metadata (baseurl: "https://download.copr.fedorainfracloud.org/results/packit/packit-stable/fedora-41-s390x/") for repository "copr_packit_packit_stable"
 Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
WARNING: DNF5 command failed, retrying, attempt #2, sleeping 10s
...
praiskup commented 2 weeks ago

Wait, are we using s390x for source RPM builds? :-/ s390x is the most scarce resource.

praiskup commented 1 week ago

Nah, this is probably breaking all custom builds (including packit): https://copr.fedorainfracloud.org/coprs/g/mock/mock-pull-requests/build/8023082/

This is the issue for the broken mirrormanager: https://pagure.io/fedora-infrastructure/issue/12183

It is acceptable to have problems like that in Fedora in the early stages of the branched version, but it is not acceptable for Copr (we should use the stable default).

praiskup commented 1 week ago

https://github.com/fedora-copr/copr/blob/cbb058f472612bccc095aa865162e0656a439050/frontend/coprs_frontend/coprs/models.py#L1027-L1030 fedora-latest solution

FrostyX commented 1 week ago

Just FTR we want to use fedora-distro-aliases for this and we discussed caching. Fedora-distro-aliases currently implements caching to have a fallback when Bodhi is down but the cache doesn't provide any performance benefits. Even if a cache exists, we try to get fresh results from Bodhi.

I don't think we should change this behavior and always use cache if cache is available but instead try something like this on Copr side:

from coprs import cache
@cache.memoize(timeout=666)  # Maybe an hour? Maybe a day?

but we should first do some testing if @cache.memoize is shared for every thread, if it survives systemctl restart httpd, and so on.