Bug 1488121
| Summary: | Monitoring page shows package has been forked but it has not | ||
|---|---|---|---|
| Product: | [Community] Copr | Reporter: | Michael Mráka <mmraka> |
| Component: | backend | Assignee: | Miroslav Suchý <msuchy> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | praiskup |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-12-06 07:51:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Michael Mráka
2017-09-04 11:23:58 UTC
The same happened to me with 'Follow Fedora branching' enabled in @db-sig/sclo-postgresql96 project. (In reply to Michael Mráka from comment #0) > Description of problem: > https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/ > monitor/ > shows > susestudio-java-client forked forked forked forked forked forked > forked > > Forked link references build > https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/ > build/593253/ > > Actual repos for some of the arches do not contain susestudio-java-client > package; e.g. > https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk- > 2.7/epel-7-x86_64/ I think, it's because the built rpm packages were not in the epel-7-x86_64 chroot dir when it was being forked. Very likely it was auto-pruned before that. prunerepo sometimes takes away packages from the latest build even if they are the latest ones but that happens only if those same NEVRAs are built in some other build as well. This is very likely what happened there. See: https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/package/susestudio-java-client/ The actual problem is in the forking algorithm in my opinion, which does not look at what is at backend but instead it just copies a build db records and it calls backend fork action for each latest successfull build of the package. It assumes, the latest successful build will have all the latest NEVRAs for each project chroot (or rather for each project chroot where the package should be built and present in the project), which might not always be true. The similar thing probably happened to Pavel as well in a slightly different flavor (e.g. a build of a package for fedora-rawhide-x86_64 and later build of that same package for fedora-rawhide-i386 -> it will actually fork just the results for fedora-rawhide-i386) but the monitor status page should correctly reflect that then and also the forked build should correctly reflect that then (showing 'forked' for forked chroots and dash '-' for all the rest). Probably Pavel's bug encounter was exactly the same (building for all the rawhide chroots, some rawhide chroot failed then rebuilding again for all rawhide chroots and it succeded). (In reply to Pavel Raiskup from comment #1) > The same happened to me with 'Follow Fedora branching' enabled in > @db-sig/sclo-postgresql96 project. And it happened again with 'Follow Fedora branching' and release Fedora28. (In reply to Michael Mráka from comment #3) > (In reply to Pavel Raiskup from comment #1) > > The same happened to me with 'Follow Fedora branching' enabled in > > @db-sig/sclo-postgresql96 project. > > And it happened again with 'Follow Fedora branching' and release Fedora28. I will look if I can improve prunerepo. If not, we will need to change the forking algo. I believe this has been fixed by: https://pagure.io/copr/copr/c/a9b4c53ecb4d1b64d7352bcf4fdda3d033d3c38d https://pagure.io/copr/copr/c/e7e661a53661844cac0fd5e0f67013b27747576f The second patch is not yet released. |