From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SUBJ_ALL_CAPS autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1519053033; bh=1Y6xylRtPNDqlurzbePyJgFaP6VR7169HwQv13rzrC0=; h=Date:From:To:Subject; b=XciGdz0EgPvpPmMH4DytE01JQbeMDqdgp2e1pmCGBgJxMQE3l9p5XZV+IsXo8KRI1 axQ+NtubaY4FrHyGpd6VClNR+f6xS99mJjFJmT+aCDgNTW3siwP99y4jHN6TDo0gBc 9a0KZxzrrngyo49L2lr6ly8NAGddtpktLMYUZbss= Date: Mon, 19 Feb 2018 17:10:32 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20180219151032.GA18209@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] =?utf-8?b?0KHQsdC+0YDQvtGH0L3QuNGG0LAgKElWKS4g0KDQtdGE?= =?utf-8?b?0LDQutGC0L7RgNC40L3QsyDQuNC80LXRjtGJ0LXQudGB0Y8g0YHQsdC+0YA=?= =?utf-8?b?0L7Rh9C90LjRhtGLLg==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:10:37 -0000 Archived-At: List-Archive: List-Post: Уважаемые господа! Продолжаю серию писем по улучшению сборочницы. Темой сегодняшнего письма является рефакторинг сборочницы. Ранее я привел несколько предложений по улучшению нашей сборочницы, которые можно внедрить, как промежуточные. Кроме того, это может ускорить производительность в несколько раз. Повторю эти предложения. * Вынести все тесты в сборочные процессы. Некоторые из них придется повторить на этапе merge, чтобы обеспечить целостность репозитория, но раз они будут выполнены повторно на той же транзакции, то существенную часть данных для тестов можно закешировать и повторно использовать, * Сделать merge явным отдельным этапом - когда сборка закончится, выставить task'y статус BUILT(ожидает merge) Сделать merge отдельным скриптом, который можно будет запускать параллельно сборочным, который будет брать из очереди task'и в статус BUILT(ожидает merge) и последовательно мержить. * Выбросить из мержа все тесты, не связанные с поддержанием целостности репозитория. Предлагаю оставить ** (кешированный) тест на наследование ** (кешированный) тест на символы в бинарниках ** тест на unmets хочу ответить на заданные вопросы. > Неочевидный выбор. По идее, все тесты, выполняемые на новом состоянии > репозитория (после создания индексов для нового состояния репозитория) - > это тесты на целостность репозитория. Возьмём, например, install check. > Если его выбросить из мержа, то мы даже не протестируем устанавливаемость > собранных пакетов в том репозитории, в который мы их отправляем. Здесь хотел бы остановиться подробнее. Все заинтересованные участники дискуссии уже, наверное, согласны с моим анализом, что мерж транзакций в репозиторий --- бутылочное горлышко нашей сборочницы. Поэтому выносим оттуда все лишнее, к примеру, тесты. Однако далее я предлагаю некоторые тесты повторить, не смотря на то, что они замедляют мерж. Почему именно их и почему не install check? Потому что эти тесты нам гарантируют __постоянное__ присутствие в репозитории некоторых свойств, еще и относительно дешево (за константное время). К примеру, потратив время при merge на тест на unmets, мы получим гарантию, что во всех итерациях репозитория unmets не будет. В отличие от него, install check никаких гарантий на будущие репозитории не дает. Хочу это подчеркнуть. Не прохождение install check -- достаточное основание, чтобы отсеять (не пропустить) пакет в репозиторий. А прохождение install check -- не достаточное основание, чтобы гарантировать, что install check будет проходить успешно и в последующих репозиториях. Не буду приводить примеры, такие примеры легко построить всем слушателям, когда пакет A нормально устанавливается неделю, месяц, год, а потом в репозиторий попадает пакет B и ломает A. Поможет ли против пакета B (со средним ожиданием в год) повторный install check? С вероятностью 99.99999% -- не поможет. Да, формально, существует вероятность, 0.00001%, что пакет-злодей B будет отправлен в тот же день и час, при чем смержится после начала билда A но до мержа A. Но проверять это бессмысленно: даже не потому, что это в bottleneck-е, одна машина поперек дороги блокирует всю трассу, даже не потому, что 0.00001%, а потому, что слона то мы и не приметили. на случай 0.00001% -- тест есть, а на случай 99.99999% -- теста нет. Когда пакет B попадет в репозиторий, он сломает install check. (а он попадет, это же у A сломается install check, а не у B) Вопрос, как мы узнаем об этом? Ответ - надо делать супербихайв=rebuild+check. Регулярно прогонять уже имеющиеся пакеты через install check, Таким образом, логическая ошибка здесь: > Если его выбросить из мержа, то мы даже не протестируем устанавливаемость > собранных пакетов в том репозитории, в который мы их отправляем. собрали A с репозиторием R_1 проверили A с репозиторием R_2 (куда A отправляем) отправили B в R_3. A сломался в R_3. Помогла нам проверка A на R_2? нет, не помогла. По сути-бесполезная проверка. install check по своей сути похож на rebuild check. Мы отправляем в Сизиф хорошие, годные, собирающиеся пакеты. А они там в Сизифе ломаются :(. Другими словами, все тесты можно разделить на 2 типа: тесты, отсеивающие пакеты, и тесты, гарантирующие некое свойство репозитория. отсеивающие тесты надо выполнять сразу после сборки, чтобы они выполнялись параллельно и ускоряли сборочницу. На тесты, гарантирующие некое свойство репозитория, придется урывать драгоценное время мержа. Поэтому желательно при мерже их ускорить: если предварительно выполнить при билде в параллельном потоке как отсеивающие, и при этом собранные символы и т.д. закешировать и повторно использовать при проверке в мерже. -- I V