Новости Отчёт mj за апрель по работе над «непрерывной интеграцией»

Тема в разделе "Новости", создана пользователем Mr. Pickles, 25 май 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    969
    Симпатии:
    246
    Уважаемое сообщество, на этот раз моя работа была сосредоточена на объединении большого количества уже открытых веток. И эта работа увенчалась успехом, так как многие из наиболее важных из них действительно были объединены. Если кратко, объединение основных веток повысило стабильность и скорость работы CI.

    Прежде чем погрузиться в вопросы PR, не давно в своём внешнем проекте мною был опубликован доклад по LCov (линейному покрытию тестирования). Тем, кто не знает, что это значит, LCov помогает проверить, действительно ли код, который вы производите, поддерживаете или тестируете, действительно подходит для тестирования. Или же, в более общем понимании, имеет ли действие, которое вы выполняете (изменяете код) тот же эффект, который вы ожидали (тестируется так, что можно сказать, что оно работает, как и ожидалось). Отчёт генерируется для каждой серии объединений открываемых затем PR. После создания отчёта, я занимался исследованием 2 основных проблем:
    • довольно «бедное» поблочное тестирование библиотек (таких как Epee) с покрытием примерно 60%;
    А теперь давайте перейдём к объединённым веткам и соответствующим результатам. Затем, как обычно, рассмотрим новые ветки. В этот раз некоторые из них уже будут объединёнными!

    Объединённые ветки

    Основные
    • CI: Адаптивное тестирование майнинга. Агломерат функциональных тестов включал в себя важный, но всё ещё нестабильный тест майнинга, который раньше давал сбой с вероятностью около 40%. В подобных не раз повторявшихся случаях люди просто игнорировали результаты такого тестирования. И это было бы не так страшно, если бы сбой касался только рассматриваемого теста (то есть, только майнинга), что представляет риск с точки зрения появлений регрессий при майнинге. Но поскольку этот тест входит в агломерат, та же ошибка появлялась в журналах в качестве окончательного вердикта, если происходил сбой любого другого мене значимого теста. Это означает, что если люди привыкнут игнорировать результаты тестирования в целом, также существует риск, что они проигнорируют и результаты других тестов, входящих в этот агломерат. К сожалению, именно это и произошло... дважды, до того, как был объединён мой PR. Я попытался спасти положение, путём внесения исправления, направленное на временное отключение функции, которая тогда работала с ошибками, но через день или около того моё исправление было должным образом заменено на окончательный авторский вариант, так что, всё было сделано достаточно быстро :) Потребовалось довольно много времени, чтобы реализовать поддержку этой ветки и сделать её приемлемой для всех рецензентов, а также настроить функцию многократного повторения тестов, чтобы доказать, что PR решает проблему, как я и обещал. Если вам не интересны подробности, вы можете ознакомиться с результатами в конце PR.
    • CI: Устранение случайных сбоев при тестировании сети. Данное исправление ошибки, ведущей к случайным сбоям, относится к той же категории, что и предыдущее исправление. Вероятность отказа составляла около 10%. Более низкий, но всё ещё досадный и создающий помеху показатель, как можно было бы подумать, если рассматривать себя в качестве виновного в сбое в результате не имеющего отношения собственного изменения. В случае с этим PR я могу записать на свой счёт обнаружение проблемы путём настройки повторяющихся тестов с последующим сообщением о результатах через IRC и реализацией варианта воспроизведения проблемы с минимальными временными затратами, позволяющей воспроизводить её локально в рамках быстрого цикла. Эта часть была сделана в сотрудничестве с wfaressuissia, который позже представил реальное решение и исчерпывающее объяснение к нему. Я также оформил PR для исправления в последней версии, а не только в главной.
    • CI: ccache для теста ubuntu. Обычная длительность теста ubuntu составляет 2 часа. При использовании ccache время сокращается до 1:25 ч, то есть, примерно на 25%. Чтобы это исправление работало (чтобы двоичные файлы можно было запускать на всех машинах, использующих версию x64), мне пришлось скомпилировать их как типовые двоичные файлы (в отличие от предыдущих). Приятный побочный эффект заключается в том, что только сейчас тест стал фактически проверять то, что распределяется среди пользователей, а не локально оптимизированные двоичные файлы для машины, на которой они были скомпилированы. В большинстве случаев нет никакой разницы между типовыми и оптимизированными файлами, за исключением немного более быстрого времени выполнения последних. Но всегда сохраняется риск, что оптимизированные файлы на самом деле будут работать иначе, чем типовые. При этом я не хочу сказать «медленнее», а просто по факту «иначе». Отныне пользователи не несут ответственности за риск.
    Второстепенные
    • Документация
    • Добавление ccache в README.md, а также в Brewfile Mac с целью упрощения автоматической установки. Это действительно всё, что нужно сделать, чтобы использовать ccache в Monero, потому что моя первая объединённая ветка позволяет обрабатывать всё это и везде автоматически.
    Недавно открытые ветки
    • Epee: Сжатие журналов в ротации. Я пытаюсь адаптировать zlib и его оболочку Boost для всех поддерживаемых систем (что и заняло большую часть времени, потраченного на данный PR). Помимо общих преимуществ внедрения полностью переносимой библиотеки сжатия, этот PR в частности должен обеспечить возможность архивации журналов Monero в ротации. Это ответ на пользовательский запрос, связанный с тем, что его журналы засоряются спамом и 5 Гб дискового пространства уходит только на хранение такого спама. Этот PR на самом деле не устраняет причину проблемы, возникшей у пользователя. Но если подобная проблема со спамом повторится, то, по крайней мере, для хранения спама потребуется всего около 100 Мб, но уже никак не 5 Гб. Считайте, что это форма защитного программирования — заблаговременная адаптация к непредвиденным ошибкам различной природы в будущем. Ветка технически готова к слиянию, но многие разработчики испытывают смешанные чувства, и для достижения консенсуса в данном случае может потребоваться некоторое время.
    • Воспроизводимые сборки: Добавление собственного PGP и хешей. Я всё настроил для того, чтобы верифицировать воспроизводимость последней версии 0.17.2.0, и теперь всё готово для реализации в будущих версиях. Пришло время наконец добавить мой ключ PGP.
    • Воспроизводимые сборки: Обновлённая документация Gitian. Пытаясь настроить RB, я заметил несколько неточностей в документации. Мы вместе с моим рецензентом, @hyc, смогли разобраться и написать несколько удобных скриптов, упрощающих процесс.
    • Тесты: Обеспечение тестового покрытия для внешних репозиториев. Оказывается, библиотека EasyLogging ++ не может быть оценена с точки зрения тестового покрытия, так как настройки покрытия кода не достигают её, и если даже это случится, библиотека всё равно их отклонит. Создав макрос с возможностью повторного использования для установки флагов покрытия кода, я смогу заставить EasyLogging ++ также создавать отчёт о покрытии кода.
    Вот и всё, что было сделано в этом месяце. Спасибо за всестороннюю поддержку, большую и маленькую :)

    ---

    Источник: mj part time coding - 3 months

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.