Автоматизация сборки

Этапы формирования дистрибутива

• Разработка
  • Сборка генератов
  • Тестирование
• Сборка дистрибутивов
• Публикация исходников
• Публикация дистрибутивов
Генерат
файл, получающийся в процессе сборки дистрибутива
• Целевой генерат: генерат, входящий в дистрибутив
• Промежуточный генерат: генерат, не входящий ни в какой дистрибутив

Генераты не хранятся в репозитории, однако некоторые из них (например, документация, скомпилированные переводы и т. п.) используются при публикации.

Автоматизация сборки

Репозиторий с примером

Как понятие «сборка» стало «оркестрацией»

• Интерпретируемые ЯП ⇒ нет понятия сборки

• Малые проекты: всё вручную
• Большие проекты: всё на CI-сервере
  • Документация
  • Тесты
  • Проверка синтаксиса

Как следствие: использование инструментов не по назначению:

• Tox (автоматизация тестирования)

  • Сборку генератов можно представить как test suit-ы
  • Но вообще-то tox не для этого
• Git hooks
  • одноуровневая (?) схема «стимул-реакция»
  • на чём писать? shell? некроссплатформенно! (WSL?)
• Github actions
  • Достоинство и оно же недостаток: на машину разработчика даже инструментальные зависимости ставить не надо
  • ⇒ работа превращается в магические пляски над чёрным ящиком
  • некроссплатформенность не имеет (?) значения (модно писать 10050 скриптов для 100500 ОС то на шелле, то на cmd)

Универсальный инструмент сборки

• Классический вариант: Make (его даже использует Sphinx).
  • off-python зависимость
  • некроссплатформенно

  • есть almost-make, но так же некроссплатформенно

• Вариант, рекомендуемый Tox: Invoke

  • Достоинство и оно же недостаток: описание действий на самом Python (синтаксически шумно)

  • Я увидел такую конструкцию в примере: c.run("rm -rf target")

  • та же сказка про белого бычка: off-python / некроссплатформенноть…
• …

Задача на самом деле сложная: предусмотреть кроссплатформеннные варианты процедуры сборки!

На примере DoIt

Сайт DoIt

• Архитектура:
  • Задания
    • Действия
    • Обновление генератов (зависимость на файлы)
      • Есть возможность определять, что такое «новое»
    • Составные задания (зависимость на задания)
• Позволяет запускать задания на языке командной строки
• Часто используемые примитивы на python

• Синтаксис Python (это и есть программа на Python)

В нашем случае нуждается в автоматизации:

• Сборка документации
• Обновление и компиляция переводов
• Запуск тестов (в т. ч. проверка стиля)
• Сборка исходного дистрибутива
• Сборка бинарного дистрибутива (собственно модуля)
• (ещё не сделано, но тоже нужно) Публикация:
  • Бинарного дистрибутива
  • Исходного дистрибутива
  • Документации

Пример dodo.py

В целом те же проблемы: шумно из-за python вместо декларативного синтаксиса, внешние команды и т. п.), но

• Развесистый workflow
• python-активности, в т. ч. уже готовые (типа того же rm)

У файлов есть время изменения, а вот время выполнения заданий (между которыми у Doit есть зависимости) Doit хранит в файле .doit.db

• Этот файл — генерат, его нельзя хранить в репозитории, самое место ему — в .gitignore

• Время от времени он портится или перестаёт соответствовать рабочей копии (например, после git reset):

  • Можно сказать doit forget что-то (или forget all)

  • Можно смело удалить этот файл

Пример

Попробуем обвязать автоматизацией MooTest

TODO

Пример

Модельный семестровый проект

Д/З

Обеспечить в семестровом проекте:

• Автоматизацию выгонки целевых генератов (документация, перевод, иное)

• Автоматизация git clean -fdx