42552 2022-04-22 16:33:09 +0300 Add option --keep-going to continue build even with errors 2025-02-13 12:38:47 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW https://bugzilla.altlinux.org/show_bug.cgi?id=42608 https://bugzilla.altlinux.org/show_bug.cgi?id=26711 P5 normal --- 1 vt placeholder 3aHyga glebfm grenka iv ldv manowar rider zerg cas oldest_to_newest 209954 0 vt 2022-04-22 16:33:09 +0300 Currently --fail-late stops build on architecture where previously build failure occurred. Please add option, like --keep-going, to continue build all subtasks even if other tasks are failed. This will be useful to build new major kernel versions with many external modules (for example, we have 42 packages for std-def) - Failed tasks not need to be deleted to continue build - thus, their build logs can be inspected later (when we announce build of new kernel); - There will be no need to delete sub-task and re-run task to continue test build multiple times after each failure (I think I did this >10 times and this took whole day of real time). 209955 1 zerg 2022-04-22 16:38:23 +0300 Есть же --swift 209956 2 zerg 2022-04-22 16:39:41 +0300 Точнее, уже --hurry 209957 3 vt 2022-04-22 16:54:48 +0300 "Hurry включает режим swift, в котором сборочница считает, что если пакет был хоть раз собран, то no need to rebuild." На сколько я понял из с Глебом сейчас другого варианта продолжения сборки кроме удаления failed subtasks нет. 209958 4 grenka 2022-04-22 17:26:08 +0300 Поддерживаю. Я когда-то себе написал скрипт, который каждые n секунд рсинкает events.M.1.log, грепает ключевую фразу task #****** for sisyphus FAILED и если получилось, грепает какой сабтаск свалился, удаляет его, повышает счётчик M и запускает таск снова. Можно заодно рсинкать и логи фейлов. 209959 5 rider 2022-04-22 17:31:36 +0300 да, я бы тоже не отказался от такой опции. Потом было бы удобно удалить из задания упавшие подзадания, добавить их в конец и запустить заново. 209998 6 zerg 2022-04-25 10:39:53 +0300 А я бы ещё при этом делал репозиторий независимо от результатов сборки, чтобы можно было сразу же работать над оставшимися пакетами. Ведь те, что собрались, зачастую нужны для сборки остальных. 237706 7 iv 2023-11-23 12:56:40 +0300 keep_going это очень круто; когда-то я сделал такой флаг для sisyphus_mipsel и sisyphus_riscv64. Для sisyphus_loongarch64 реализация выглядит так: https://git.altlinux.org/people/iv/packages/girar.git?a=commitdiff;h=af466d56756672c15a13e8da0a2392a923cc363c (в этом коммите нет интерфейса для пользователей). Очень помогает при массовых пересборках и приезжающих из основного Сизифа огромных таксках. 237707 8 iv 2023-11-23 12:58:09 +0300 (In reply to Sergey V Turchin from comment #6) > А я бы ещё при этом делал репозиторий независимо от результатов сборки, > чтобы можно было сразу же работать над оставшимися пакетами. +1, можно было бы подключить таску к хешеру и чинить то, что там не собралось. Но это кажется темой отдельной баги. Такая есть? 259139 9 zerg 2025-02-13 11:49:05 +0300 (Ответ для Ivan A. Melnikov на комментарий #8) > > А я бы ещё при этом делал репозиторий независимо от результатов сборки, > > чтобы можно было сразу же работать над оставшимися пакетами. > +1, можно было бы подключить таску к хешеру и чинить то, что там не > собралось. Но это кажется темой отдельной баги. Такая есть? Да, полно: #26711 #33069 #39850 #51923 259146 10 3aHyga 2025-02-13 12:38:47 +0300 (Ответ для Vitaly Chikunov на комментарий #0) > Currently --fail-late stops build on architecture where previously build > failure occurred. > > Please add option, like --keep-going, to continue build all subtasks even if > other tasks are failed. > > This will be useful to build new major kernel versions with many external > modules (for example, we have 42 packages for std-def) > - Failed tasks not need to be deleted to continue build - thus, their build > logs can be inspected later (when we announce build of new kernel); > - There will be no need to delete sub-task and re-run task to continue test > build multiple times after each failure (I think I did this >10 times and > this took whole day of real time). Какъ врѣменное рѣшеніе могу предложить чѣмъ самъ большуюсь врѣменами. https://github.com/majioa/rebuild