Как правильно хранить файлы настроек в репозитории?

Вынес часть настроек (например путь к файлику бд, порт приложухи и т.п.) в отдельный файл - возник вопрос в каком виде его хранить в репозитории? Закоммитить его с некими начальными параметрами, которые подойдут для желающих сделать git clone и запустить на посмотреть приложуху а потом добавить его в gitgnore и уже у себя менять как мне там в процессе дальнейшего байтомарания понадобится?

Да, просто дефолтный конфиг хранить в репе, а локальный менять как хочется. Естественно, по-хорошему надо бы иметь более приоритетный и менее приоритетный путь к конфигу. В опакеченном виде дефолт в итоге окажется в /etc, а если юзер захочет юзерский — скопирует файл к себе в ~/.config и изменит как хочет. Ну и ты для своихбайтомараний там же будешь развлекаться. Опционально, как вариант, программа может создавать там дефолтный конфиг при первом запуске, а юзер может его править как хочет.

Вот приложуха обрабатывает определенные входящие файлы. Для тестов сделал эталонные версии этих файлов без каких-либо реальных данных, просто нужного формата и вида. В принципе нет никаких проблем их опубликовать. Но они занимают некоторое количество места, и чисто логически стороннему пользователю ни к чему.

Я бы отдельную репу сделал. Но вообще вот тут мне тоже интересно, кто как делает — может есть более элегантное решение.

Естественно, по-хорошему надо бы иметь более приоритетный и менее приоритетный путь к конфигу.

Отлично, как-то не подумал об этом сначала.

До опакечивания еще далеко, даже не загадываю на это дело пока :)

более приоритетный и менее приоритетный путь к конфигу

Ещё можно делать fallback - embedded config с записью его в ~/.config/… если ни один конфиг не найден в ожидаемых местах.

Написать что-то типа config.example.cfg с какими-то умолчальными параметрами и хранить его в репе. Приложуха же пусть читает config.cfg. Главное не забывать поддерживать config.example.cfg в дефолтном состоянии.

Для тестов сделал эталонные версии этих файлов без каких-либо реальных данных, просто нужного формата и вида. В принципе нет никаких проблем их опубликовать. Но они занимают некоторое количество места, и чисто логически стороннему пользователю ни к чему.

https://git-lfs.com/ если это бинарники

Как правильно организовать их хранение? Отдельная репа для кода с тестами и эталонами?

отдельная репа, втыкать через сабмодуль.

Обычно я коммичу что-то вроде config.local.example. А в gitignore добавляю config.local. Разработчик должен после чекаута скопировать config.local.example в config.local и подправить что нужно под себя.

Кроме этого стараюсь делать так, чтобы и без config.local программа в каком-то виде запускалась и как-то работала. Не для всех проектов применимо, но обычно получается.

В идеале я бы хотел прямо в репозитории держать config.local, но при этом так, чтобы можно было его локально править и эти правки гит игнорировал бы. Тогда можно было бы избежать ручного копирования. Но такого функционала в гите нет.

Все тесты должны быть в репозитории, конечно, со всеми нужными для них файлами и запускаться автоматически при сборке проекта.

а зачем тебе хранить что-то личное в публичной репе?
в репе - шаблон с комментами, в тестовом пайплайне - +1 copy-операция, для тестовой среды.</trldr>

конфиг положи в файл name.conf.example или name.conf.default, а name.conf добавь в .gitignore

тестовые данные сложи в отдельную репу вместе с тестами если прям лишние, если не очень, то в эту же и сделай типа make test чтоб проверить сборку можно было

Закоммитить его с некими начальными параметрами

да, и потом не забыть в .gitignore добавить

Вот приложуха обрабатывает определенные входящие файлы. Для тестов сделал эталонные версии этих файлов без каких-либо реальных данных, просто нужного формата и вида. В принципе нет никаких проблем их опубликовать. Но они занимают некоторое количество места, и чисто логически стороннему пользователю ни к чему.

Как правильно организовать их хранение? Отдельная репа для кода с тестами и эталонами?

Обычно тесты и данные для них лежат в той же репе в папке тест. Например, тесты xz https://github.com/tukaani-project/xz/tree/master/tests/files

.env в гитигнор, а sample.env в репозиторий кладешь

в каком виде его хранить в репозитории?

https://12factor.net/

Согласно методологии Twelve-Factor, конфигурация приложения должна храниться в среде исполнения (environment variables).

Ключевые принципы:

1. Строгое отделение конфига от кода: Конфигурационные данные (подключения к БД, внешние API-ключи, параметры хоста) не должны находиться в кодовой базе.
2. Явное объявление: Все параметры конфигурации должны быть явно объявлены в среде выполнения.
3. Группировка по окружениям: Разные окружения (development, staging, production) представляются разными наборами переменных окружения.

Преимущества:

• Безопасность: Учетные данные не попадают в систему контроля версий.
• Гибкость: Конфигурация может изменяться без пересборки или переразвертывания приложения.
• Масштабируемость: Легко создавать новые окружения с уникальными конфигурациями.
• Совместимость: Универсальный стандарт для любых языков программирования и платформ.

Антипаттерны:

• Хранение конфигов в файлах внутри репозитория (например, config.json, .properties).
• Группировка конфигов по типам окружений («dev», «prod») в коде.

Источник: The Twelve-Factor App: Config

Только хотел про 12-factor написать. Но это больше про backend приложения (хотя, как мне показалось, вопрошающий отчасти про них и спрашивал).

Что касается практик: да нет тут никаких правил. Если целишься сделать сервис - лучше придерживаться 12-factor и ожидать, что тебя запустят в Docker, то есть файла конфига в виде файла лучше не иметь вообще, если это возможно, либо, как минимум уметь переписываеть его из энвов.

Если юзверьское приложение делать - то нужны sane defaults, которые работают без конфига вообще, а также желательно, чтобы приложение могло сгенерировать дефолтный конфиг само. А так - XGD_CONFIG_HOME/appname/file - и вот тут и хозяйничай.

Если cli-приложуха, то в идеале бы ей уметь генерировать completions для разных оболочек.

Что касается репозитория:

1. Держать пример конфига прямо в репозитории - отличная идея (главное не закоммитить секреты, хотя есть и практика хранения зашифрованных секретов для разных окружения прямо в репозитории с кодом, если что).
2. Держать тесты в репозитории - отличная идея. Так и запустить их быстрее и CI проще настроить, и видно, что ОНИ ЕСТЬ :) Иногда тесты могут подсказать что-то о работе приложения читающему код.

И общий совет - можно побродить по github и посмотреть, у кого как сделано…

Лучше всего в репозитории держать example config, но такой, который сразу заработает. Здесь можно сотни разных улучшайзеров сделать: мастер настроек, который генерирует конфиг; сама прога без конфига пишет дефолтный конфиг куда-нибудь – в зависимости того кто пользователь. Разработчики в принципе легко разберутся как сделать конфиг, но могут напрячься запускать без контейнеров.

Файлы для тестов лучше сделать как можно меньше. Если никак, то выложить их куда-нибудь в другое место: отдельный гит, s3, возможность сгенерировать, итд. Но только для больших файлов, сам код тестов лучше оставить в проекте, но сделать чтобы при отсутствии ассетов некоторые тесты пропускались.

Спасибо всем за ответы, немного выпал в irl по всяким грустным причинам.

Пока думаю мне хватит варианта с config.example и заигноренным локальным конфигом.

тесты xz

masa очень годный пример, спасибо за ссылку.

12-factor полистал - пока чуть выше моих навыков, но уже вижу ответы на мои следующие непонятки, поэтому тоже большое спасибо :)

Если приложение веб, то обычный подход: настройки читаются из переменных окружения. В репозитории файл env.sample, в котором приведены значения для примера. При развертывании у себя, первой командой выполняется cp env.sample .env, а уже .env загружается как удобно: либо командой source .env, либо через docker/docker-compose.

Это не единственный способ, но самый простой и популярный.

Единственное, что очевидно - настройки никогда не должны быть под контролем системы версий, иначе неизбежно в репозитории попадут секреты, которых там не должно быть, да и банально неудобно всегда помнить, что у тебя есть файл, который помечен, как изменённый, но его ни в коем случае нельзя коммитить.