On Thu, Dec 17, 2020 at 9:11 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Wed, Dec 16, 2020 at 03:56:25PM -0500, Neal Gompa wrote: > ...snip... > > > > What I'd really like would be a "test mass rebuild" process, where a > > > > prospective package is uploaded and everything that depends on it is > > > > automatically rebuilt (ideally after creating the dependency graph so > > > > each individual package doesn't get rebuilt until its dependencies are > > > > finished building). > > > > > > > > Creating the dependency graph by hand is fairly tedious, but maybe I'm > > > > missing an automated way. The point of creating that graph is to avoid > > > > wasting time and power doing and redoing builds that will fail until > > > > something else has been built (which is the problem with mock's > > > > --chain command, if I understand correctly). > > > > > > > > Once I have that graph, I use Make to control the process, because it > > > > handles the dependency graph, as well as parallelism, and not > > > > rebuilding things unnecessarily. > > > > > > Yeah, all this ^ > > > > > > > So I've written tools for doing this, and Igor has written tools for > > doing this, but it seems like people think that this is "impossible" > > and so the effort goes nowhere despite several PoCs. > > > > If we're interested in this again for real this time, I could try to > > dig out my old code for it, but we might be better off just pulling > > out Koschei's code and turning it into something that Koji's > > chain-build command and Mock's --chain option use to sort through > > package sets and build them correctly. > > Can you expand on which 'this' you mean? Getting the build > order/dependency graph? Or a tool to use that to rebuild everything and > tell you what failed? or ? > > I don't think you can ever be 100% on dependency graph/build order, > because there's sometimes bootstraps or loops in there. :( > > Anyhow I would love to be able to locally build a new library and run > 'fedpkg does-it-blend foo.src.rpm' and have it tell me exaclty what > other packages that breaks. That feature was implemented [1] in Koschei long time ago, but it is not enabled in Fedora production instance of Koschei due to Copr not completing RFR [2]. It should be deployed in Fedora staging instance of Koschei. You can build one or more package updates locally or in Copr and send request to Koschei to test the set of packages. Koschei will check which packages are affected by the update by resolving dependencies and running builds in Copr. Koschei provides an overview page saying which packages were affected (broken or fixed) by the update. Another variant of this feature was implemented [3] more recently without reliance on Copr - it makes use of Koji side tags. It was intended to be integrated with CI and gating - Koschei can test side tags and emit results to messaging bus in CI format [4] that is understood by CI system and can be used by packagers to implement gating for their packages. Again, this feature is not enabled in production, only in staging. [1] https://github.com/fedora-infra/koschei/issues/113 [2] https://pagure.io/fedora-infrastructure/issue/5166 [3] https://pagure.io/fedora-ci/general/issue/45#comment-606344 [4] https://pagure.io/fedora-ci/messages > > kevin > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
