Propose erlang reusable workflow

[kehitt]

Мне кажется, что в reusable workflow можно (и нужно) отказаться от внешней конфигурации make, которая, по сути, наполовину определяет работу пайплайна CI. Это позволит, как минимум, не заморачиваться возможными различиями/ошибочными изменениями от репозитория к репозиторию.

Само право на существование makefile со всеми wc-/wdeps- фичами это, конечно, не затрагивает, но кмк это больше уровень QoL разработчика.

[ndiezel0]

Не согласен, по моему мнению работа через Makefile позволяет нам репродуцировать работу CI на локальной машине, что очень помогает в отладке. К тому же CI через workflow проверяет работу на раннере, который к образу никакого отношения не имеет, а не в финальном образе, который и будет задеплоен. Грубо говоря: мы можем не положить в образ нужную зависимость и не заметить это на CI.

[kehitt]

Не согласен, по моему мнению работа через Makefile позволяет нам репродуцировать работу CI на локальной машине, что очень помогает в отладке.

Нет, тут я конечно согласен, удобно.

Основной моей идеей тут было то, что раз у нас появляется organisation-wide workflow, не плохо бы заставить его автоматически енфорсить какие-то organisation-wide политики, к примеру - "организация требует запускать dialyze в тестовом профиле", "организация требует предоставлять статистику по coverage", и тому подобные. Тогда получится, что вместо того чтобы постоянно проверять эти вещи от репозитория к репозиторию (от PR к PR), можно будет просто проверять что мы используем этот reusable workflow и потому имеем какие-то гарантии.

Long story short, мне не очень нравится, что в Makefile можно написать exit 0 и получить зеленую галочку на PR, особенно в контексте того что мы успешный опенсурс и у нас тысячи PRов от третьих лиц в неделю. 🌝

Я не спорю, что этот подход больше не будет обеспечивать полное соответсвие окружений Makefile и CI, что может быть не удобно. Основные параметры этих окружений, вроде версии OTP, все еще можно будет синхорнизировать через .env, но обеспечить соответсвие уровней ниже, конечно, будет сложнее (хотя получается, что если ты сидишь на M1, то его все равно не будет, даже через Makefile). Плюс пока не очень понятно как заносить, например, генерацию swag (через rebar pre_hook?).

В общем, мне интересно ваше мнение по поводу целесообразности этой затеи в целом. Конкретную реализацию можно допилить в процессе, но если в этом обсуждении мы установим, что мои беспокойства напрасны, то конечно нету смысла 🥐

К тому же CI через workflow проверяет работу на раннере, который к образу никакого отношения не имеет, а не в финальном образе, который и будет задеплоен. Грубо говоря: мы можем не положить в образ нужную зависимость и не заметить это на CI.

Но ведь и Makefile проверяет работу не в образе, который будет задеплоен (второй FROM в Dockerfile), а в девелоперском (Dockerfile.dev). Мне кажется что такую проблему лучше решить внесением изменений в воркфлоу, который делает, собсвтенно, релизы, чтобы он каким то образом пытался запустить то, что он только что собрал, хотя бы до уровня базового хелсчека.

[kehitt]

По просьбе @keynslug, примерно то, как подключать:

• Файл .env:

OTP_VERSION=24.2.0
REBAR_VERSION=3.18
THRIFT_VERSION=0.14.2.1

• Файл .github/workflows/ci.yml:

name: Erlang Service CI

on:
  push:
    branches:
      - 'master'
      - 'epic/**'
  pull_request:
    branches: [ '**' ]

jobs:
  setup:
    name: Load .env
    runs-on: ubuntu-latest
    outputs:
      otp-version: ${{ steps.otp-version.outputs.version }}
      rebar-version: ${{ steps.rebar-version.outputs.version }}
      thrift-version: ${{ steps.thrift-version.outputs.version }}
    steps:
      - run: grep -v '^#' .env >> $GITHUB_ENV
      - id: otp-version
        run: echo "::set-output name=version::$OTP_VERSION"
      - id: rebar-version
        run: echo "::set-output name=version::$REBAR_VERSION"
      - id: thrift-version
        run: echo "::set-output name=version::$THRIFT_VERSION"

  run:
    needs: setup
    uses: valitydev/erlang-workflows/.github/workflows/erlang-parallel-build.yml@acbc73d39b4dd630d9c797ddaeb8af92fb071014
    with:
      otp-version: ${{ needs.setup.outputs.otp-version }}
      rebar-version: ${{ needs.setup.outputs.rebar-version }}
      thrift-version: ${{ needs.setup.outputs.thrift-version }}

Все остальные Dockerfile/Makefile/docker-compose.yml взять отсюда (в будущем перенести в valitydev/erlang_templates).

[keynslug]

Само право на существование makefile со всеми wc-/wdeps- фичами это, конечно, не затрагивает, но кмк это больше уровень QoL разработчика.

Я это если честно так же вижу. Отсюда собственно корни этих файлов .env и растут.

В моём представлении нам надо как-то добиться удачного компромисса между (потенциальной) воспроизводимостью CI активностей и продуктивностью разработчика. И в этом смысле непонятно, что бы мы выиграли, если бы CI активности в контейнере гоняли: по моей оценке в воспроизводимости мы бы особо не выиграли (потому что идеальной не добиться из-за различий сред исполнения), а в продуктивности − потеряли (потому что в CI становится замешан make, сборка контейнеров, и он работает медленнее).

Грубо говоря: мы можем не положить в образ нужную зависимость и не заметить это на CI.

Поддерживаю @kehitt, это же всё равно не достигается тем, что ты make wc-xref дёрнешь на CI вместо rebar3 xref. А тем, что ты собранный образ запускаешь с конфигом из репозитория и проверяешь его жизнеспособность.

[ndiezel0]

Может тогда на него и полагаться, а не на значение inputs.run-ct-with-compose?

[kehitt]

Как-то не очень очевидно будет, лучше тогда service-name сделаю required.

[ndiezel0]

Ну если правильно назвать, то должно быть очевидно) compose-service-name и описание, что делает.

[keynslug]

Го мержить и тэгать? 💣