Синопсис
До проекта Summer of Bitcoin в Cryptoanarchy Debian Repo (CADR) отсутствовала непрерывная интеграция (CI), что беспокоило новых участников, поскольку настройка среды разработки может быть сложной. В итоге я успешно внедрил CI, используя стандартные бегунки GitHub Actions. CI может быть запущен вручную, или путем отправки PR, а также при помощи push непосредственно в мастер-ветку.
CI разделен на 2 задания:
- Первое — это задание сборки. Оно создает образ среды podman, загружает образ в Artifacts для повторного использования. Затем с помощью среды podman собирает пакеты CADR, проверяет их сумму sha256, а затем загружает собранные пакеты Debian, а также их суммы sha256 в Artifacts.
- Второе задание — тестовое. Оно запускается после завершения задания сборки. Задания тестирования выполняются параллельно для каждого пакета. Сначала задание тестирования загружает собранные образы и пакеты Artifacts, загруженные в задании сборки, затем использует
make test-here-basic-%иmake test-here-upgrade-%(% для имени пакета) для запуска тестов.
Путь реализации
Первая попытка
Сначала я проигнорировал тот факт, что уже существует dockerfile для CADR (хотя он и не предназначен для сборки), и настроил свой собственный dockerfile с нуля, добавляя зависимости при возникновении ошибок.
Оказалось, что мой собственный dockerfile отлично работает на GitHub Actions для процесса сборки, но не работает для процесса тестирования.
Первоначально я подумал, что это были проблемы с зависимостями, поскольку тест может работать на моем собственном компьютере.
При проверке журналов я обнаружил, что это связано с проблемой unshare.
Затем я заметил, что добавление параметра --privileged может решить проблему unshare для docker. Но после этого возникла проблема с systemd. Наконец я заметил dockerfile в кодовой базе, который уже существует для CADR, и так же, как это работает, я заставил systemd запуститься в качестве первого процесса.
VOLUME [ "/sys/fs/cgroup" ]
CMD ["/lib/systemd/systemd"]
и добавить --tmpfs /tmp --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro в качестве дополнительных параметров, чтобы разделить некоторые ресурсы хост-машины и сделать ее контейнером демона. Операции выполняются с помощью docker exec для присоединения к контейнеру. Но это все равно не решило проблему с systemd.
Наконец я перешел на podman, и проблема с systemd была решена (он поддерживает --systemd=true), потому что я случайно нашел эту статью, когда гуглил эту проблему.
Однако, возникла новая проблема, предлагающая не удалось переопределить dbcache.
В журналах рабочего процесса не видно никаких ошибок, хотя отсутствующая зависимость bc была исправлена, и я могу подтвердить, что команда здесь работает правильно в контейнере, запущенном на моем ПК. Более того, когда я вручную пропускаю только что упомянутый тест, тест далее показывает, что есть ненужный реиндекс:
Что позволяет предположить, что это связано с проблемой 108, возможно? Я открыл проблему здесь. Я могу пропустить этот тест, но дальнейшая ошибка говорит о том, что electrs недоступен. Это может быть исправлено с помощью этого PR
Даже если эти проблемы будут исправлены, все равно может потребоваться другая платформа, поскольку полный тест требует слишком много места:
Только тестирование части regtest будет в порядке без проблем с пространством.
Исправление тестов
Первая проблема — выяснить, почему переопределение dbcache не работает. На поиск решения у меня ушло несколько недель. Первоначально при определении размера биткоин dbcache вызывается bc. Но bc не гарантированно установлен, поэтому он может не сработать. Тогда вместо того, чтобы заниматься математическими вычислениями, я подал PR, чтобы просто сопоставить диапазоны: RAM < 1024 -> default dbcache, RAM < 2048 -> dbcache=512, …, RAM => 8192 -> dbcache=4096. Однако при запуске в рабочем процессе GitHub Actions с этим PR ошибка переопределения dbcache все еще существует. Это очень странно, так как когда я запускаю тест вручную, используя те же методы из рабочего процесса с контейнером podman на моем ПК, такая проблема не появляется. Таким образом, проблема, похоже, принадлежит только среде рабочего процесса GitHub Actions, несмотря на то, что он запущен в контейнере.
Затем, после долгих проб и ошибок, я наконец нашел виновника. Ссылаясь на PR, ранее debcrafter отбрасывал все возможности, что, похоже, вызывает ошибки, когда возможности ядра хоста не совпадают с теми, которые известны setpriv. Нам нужно отбрасывать только возможности, поддерживаемые текущим ядром.
Затем я отправил PR для исправления этого, и он был объединен.
Вторая проблема заключается в том, чтобы выяснить, почему существует ошибка с ненужным реиндексом. Я заметил, что хотя тест не прошел на test-here-basic-electrs с ненужным reindex при запуске make test, запуск одного только make test-here-basic-electrs не приводит к ошибке. Итак, до исправления этой проблемы я предполагал, что, возможно, это все еще связано с проблемой 108, которая заключается в том, что после обновления существующих не обрезанных узлов в экспериментальном -reindex использовался, несмотря на то, что обрезка не была изменена. Или тестовое окружение не было очищено перед test-here-basic-electrs при выполнении make test. Мой конечный результат доказывает, что верно последнее, и я отправил PR для очистки маркера режима цепочки, поскольку мы хотим, чтобы он был чистым с помощью package_clean_install.sh
Я также отправил PR для принудительной установки версии linked-hash-map на 0.5.4 для исправления проблемы сборки debcrafter, которая только что возникла в период проекта.
Тест может быть успешным на GitHub Actions, если тестировать только с помощью regtest и после слияния PR 200, 201, 203, 204.
Исследование облачного провайдера
Я также исследовал, какой облачный сервис использовать, так как мы планировали использовать самораспространяющийся бегун GItHub. Я проверил поставщиков облачных услуг AWS, Google Cloud и Azure. Я обнаружил, что GitHub Actions использует Azure в качестве бегущей строки по умолчанию, поэтому для создания самостоятельной бегущей строки GitHub, Azure будет хорошим выбором, если мы используем того же провайдера, что и бегущая строка GitHub по умолчанию. Кроме того, у Azure есть пробный период с 200 долларами на один месяц при создании новой учетной записи, так что мы можем начать бесплатно, в то время как другие поставщики облачных услуг не предлагают такой большой скидки.
Исследование других возможных CI-платформ
Я выяснил, что в отличие от GitHub Actions, который запускает CI на виртуальной машине, Travis CI, GitLab CI/CD, Jenkins все запускают предопределенные для CI контейнеры Docker без поддержки systemd. Значит, запустить внутри такого контейнера podman-контейнер с поддержкой systemd будет невозможно. Azure DevsOps является подходящим вариантом для нашего случая использования, и я также пытался его использовать. Затем я заметил, что для одного задания CI, каждый шаг, он позволяет только 1 час максимум, иначе он будет отменен, в то время как наше задание сборки, а также задание полного чистого тестирования длится намного дольше 1 часа, это также не подходит для нас. Тогда, наконец, GitHub Actions будет единственным хорошим выбором.
Самостоятельное размещение бегунов для GitHub Actions
Я также пытался самостоятельно использовать службу Azure Virtual Machines для установки Self-hosted runners для GitHub Actions, но похоже, что среда не очищается автоматически каждый раз и загрязняется от предыдущих запусков.
Разделяй и властвуй
Наконец-то я придумал новый способ тестирования. Мы можем использовать метод «разделяй и властвуй», чтобы обойти проблему нехватки дискового пространства, а также проблему загрязненного окружения при запуске тестов как на mainnet, так и на regtest. Я вижу, что тест make состоит из make test-here-basic-% и make test-here-upgrade-%(% для имени пакета), мы можем просто использовать матрицу в GitHub Actions для тестирования каждого пакета в отдельных средах, и тогда дискового пространства будет достаточно, а PR 204 можно закрыть, потому что теперь у нас всегда есть чистая среда.
Затем я успешно реализовал и протестировал этот метод, и он работает! Таким образом, сейчас идет полное тестирование, и я достиг цели проекта даже с решением, которое не требует денежных затрат на создание и тестирование CI!
CI может быть успешным, если предыдущие тесты, исправляющие PR, будут слиты первыми.
Окончательные результаты
После рецензии моего наставника @Kixunil я начал использовать параметр --locked, чтобы заставить карго использовать cargo.lock, который содержит правильные версии. Также я исправил проблему безопасности, сделал учетную запись пользователя user и сборки/тестирования с user, и сделал загрузку результата sha256sum для собранных deb пакетов, чтобы люди могли проверить хэши.
Кроме того, я исправил тесты для bitcoin-regtest после включения nosettings bitcoind в PR 205. После этого в ядре должна быть какая-то ошибка, связанная с разницей в расположении кошельков на GitHub runner и физической машине, поэтому PR был закрыт, и было зафиксировано другое решение, которое делает тесты независимыми от расположения кошелька.
CI успешно работает с вышеуказанными изменениями, и все работает хорошо, ничего больше не нужно делать.
Заключение
Мой проект Summer of Bitcoin — это большой опыт для меня, так как я узнал много нового о Bitcoin и связанных с ним знаниях DevOps.
Если вы интересуетесь биткойном и хотите начать вносить свой вклад в Cryptoanarchy Debian, используя мою работу, вы можете легко форкнуть репо и добавить больше тестов или новых пакетов, зафиксировав код в мастер-ветке вашего форка на GitHub, CI поможет вам собрать deb-пакеты и найти возможные ошибки, не нужно снова настраивать среду разработки на вашем компьютере.
Резюме PRs
Объединено
- [SoB] Добавить рабочий процесс GitHub для CI
- Исправление libcap-ng слишком устарела для ‘всех’ прописных букв
- Удалить зависимость bc для переопределения dbcache
- Замените все apt на apt-get в test
- Попробуйте несколько раз проверить подключение к electrs-regtest
- Установите файл журнала bitcoind в /var/log
- Установите настройки nosettings bitcoind включенными по умолчанию
Закрыто как решенное другим способом
- (Проблема) Ошибка: тест не прошел для bitcoin-regtest с ошибкой ненужного переиндекса для test-here-basic-electrs
- Исправление ошибки ненужного переиндекса при выполнении тестов
- Исправьте тесты для bitcoin-regtest после включения параметра bitcoind nosettings
- Установите версию linked-hash-map равной 0.5.4
- rustyline downgrade до 6.3.0 для исправления проблемы компиляции