Я решил подключить всё, что у меня есть из домашних сервисов, в одну CI/CD и сделать это на homelab. Тема CI/CD, набившая оскомину мне лет 15 назад, когда я поставил свой первый Jenkins. Потом были TeamCity, Travis, GitLab и другие. Но единственное решение, которое оставило приятные воспоминания - Drone CI. Если вы искали хороший self host CI, без лишних фичей, настоящий open source, то ниже попробую вам помочь.

-> Пример веб приложения на Rust с Woodpecker CI

Философия Дятла

Главное преимущество - ты можешь запустить сценарий CI/CD прямо на своей машине с помощью родного CLI, а также запустить сборку с сервера в его контексте также на своей машине. Это делает работу с реальным CI/CD компании менее раздражающей. А также изменяет отношение вас как разработчика к серверу сборок.

Мне было приятно пользоваться Drone после Jenkins. Это был глоток свежего воздуха и язык сценариев был прост. Потом Drone поменял лицензию и стал корпоративным решением. Появился его форк — Woodpecker CI, который является альтернативой GitHub Actions для платформы Codeberg.org (GitHub из Берлина).

Локальный запуск возможен и в других решениях: GitHub Actions имеет CLI act, GitLab имеет утилиту local runner. Но запуск локальных тестов в них работает не так, как на самом сервере — я убедился в этом при первой попытке использования act. В Drone же локальный запуск — это не дополнительная утилита или плагин, а сам дизайн решения. В этом суть его философии: ты можешь начать пользоваться CI сразу, без лишней сложности и DevOps овёрхеда.

Тестовый проект

Создадим папку нашего проекта, папку для всех сценариев CI/CD и первый сценарий.

mkdir -p woodpecker-test/.woodpecker && touch woodpecker-test/.woodpecker/hello-world-flow.yaml

Установка Woodpecker-cli с помощью mise. Подробей тут

mise use --global aqua:woodpecker-ci/woodpecker/woodpecker-cli

Заполним файл сценария.

hello-world-flow.yaml

when:
  - event: manual

steps:
  - name: build
    image: bash
    commands:
      - echo "This is the build step"
      - sleep 5

И мы уже готовы запустить наш сценарий для будущих сборок с помощью CLI woodpecker-cli.

woodpecker-cli exec

# hello-world-flow.yml
[build:L0:0s] + echo "This is the build step"
[build:L1:0s] This is the build step
[build:L2:0s] + sleep 5

Да, да! Таким образом существует в мире возможность начать проект не с инициализации через cargo new или npm create. А с того чтобы описать что вы решили собрать и запустить.

Поговорим о yaml нашего workflow для woodpecker. Мы видим язык для определения шагов выполнения. Каждый шаг требует условия для запуска. И обычно условием будет что-то вроде

when:
  - event: push
    branch: master-of-the-zoo

when:
  - event: [push, pull_request]

Мы не можем не указать условия, шаг не будет исполнен. А если мы укажем pull-request или push,
woodpecker-cli локально тоже не станет запускать шаги. Есть несколько способов для запуска сразу, это использование условия

- evaluate: "true"

Либо CI_PIPELINE_EVENT=manual, что дает больше информации о том что происходит.
Можно передать любую другую env при вызове и сделать проверку.
Еще вариант указать event как manual. Собственно то, что и надо использовать.

when:
  - event: [push, pull_request]
    branch: master
  - event: manual

Если сборка завалилась уже на сервере woodpecker, то можно через UI скачать metadata файл, который, переданный через аргумент при запуске сценария, будет содержать информацию о том, что произошло событие пуша нового коммита, и сценарий также будет выполнен.

 woodpecker-cli exec --metadata-file metadata.json

Итого

Мы попробовали пока только запуск очень короткого сценария. Для понимания целиком надо еще разобраться в том как поднять сервер и агенты. Как их настроить. Как реализовать Deploy скрипты с помощью Дятла и тп. Но это тема для следующей статьи.
Больше заметок как пользоваться Woodpecker я выкладываю на mdbook github. Там можно найти пример web app на Rust, как сделать весь pipeline.

Простой, не полный по фичам, но оставляющий хорошее впечатление CI/CD решение Woodpecker. Его maintainer'ы отвечают очень оперативно на github, но с довольно мертвым чатом на матриксе. Хотя для них родной Forge это Codeberg. Документация достаточная, но не ждите идеальной.
Дятел CI подойдет тем кто ищет полноценный open source и self hosted решение. Для тех кому не нужен k8s native.

Источники