Если в тестовом задании в p8 обнаружилось, что версия пакета больше сизифной, то репозиторий не создается, из-за чего я не могу протестировать в p8 пакет в то время, когда лучше, а не когда сборочница соизволит разрешить. В это время в sisyphus такое же задание ожидает проверки в другое более подходящее время. Хотелось бы иметь репозиторий при ошибках подобного рода хотя бы. А лучше при любых, т.к. обычно собранная часть сборочного задания необходима для продолжения работы над остальной частью.
Как отличить ситуацию "одноименный пакет скоро будет в сизифе" от ситуации "ошибочная версия-релиз при сборке пакета в бранч"?
Разве сгенерированный репозиторий помешает отличить? Это ж ресурсов отнимет совсем чуть.
(In reply to comment #2) > Разве сгенерированный репозиторий помешает отличить? Это ж ресурсов отнимет > совсем чуть. Совсем чуть. И анметы с остальными проверками, и тестовая установка пакетов - всё это ничего не стоит.
Я уже давно научился выкачивать в локальных хешер. Неудобно, но что делать: lftp http://git.altlinux.org/tasks/183809/build lftp :~> mget */i586/rpms/*
Мое, например, рабочее время стоит вполне конкретных денег. Я знаю, как его сэкономить у меня и у других. Решайте сами.
(В ответ на комментарий №4) > Я уже давно научился выкачивать Так не работает. x86_64-i586 или нет или вообще от прошлой итерации.
(В ответ на комментарий №6) > Так не работает. x86_64-i586 или нет или вообще от прошлой итерации. Хотя, x86_64-i586 при недособранном таске мне не нужен.
Пинг. А то придётся городить костыль в виде выкачивания пакетов и создания собственного репозитория с upload на ftp. Как вариант - можно поднять отдельную очередь, пакеты из которой никогда не попадут в репозиторий. Я буду отправлять туда задания, а потом оттуда копировать в основную (после проверки). Мы реально ждём прохождения очереди для тех заданий, результат которых нужен срочно здесь и сейчас.
(In reply to comment #8) > Пинг. Если вы меня пингуете, то рано ещё, пингуйте по возвращении.
(В ответ на комментарий №9) > (In reply to comment #8) > > Пинг. > > Если вы меня пингуете, то рано ещё, пингуйте по возвращении. Багзилла, к сожалению, не сообщает о твоём местоположении и мы понятия не имеем где ты и что делаешь.
(In reply to comment #10) > Багзилла, к сожалению, не сообщает о твоём местоположении и мы понятия не имеем > где ты и что делаешь. Отдыхаю после lpc и cauldron'а, странно, что вы не в курсе, но это offtopic. До связи.
Я не понял, какую именно из родственных задач вы хотите решать, поэтому задам уточняющие вопросы. Вы хотите, чтобы проверка версий откладывалась (если да, то до какого момента), или чтобы обработка результата проверки откладывалась (если да, то до какого момента)? Как вы хотите, чтобы то поведение, которого вы хотите, было связано с --fail-early/--fail-late?
Нам нужно что бы проверка версий не вызывала ошибку сборки и выполнялась только перед commit'ом таска. Т.е. - что бы задание с ошибкой версий доходило до QA в состоянии EPERM. Лучше, наверное, откладывать обработку результатов - что бы QA знали, что задание после проверки не пройдёт из-за версий, но те, кто ждут его в production - могли бы уже тестировать пакеты.
желаемое поведение хочется иметь по умолчанию без учёта опций fail-late
(В ответ на комментарий №12) > Как вы хотите, чтобы то поведение, которого вы хотите, было связано с > --fail-early/--fail-late? Чтоб сперва создавался репозиторий, а fail был позже.
Реализовано в таком виде: https://lists.altlinux.org/pipermail/sisyphus-incominger/2019-October/545676.html girar commit e97c31ab386c40d66c99bc44de2ed64a93d8b355.
