Как сделать так, чтобы при merge не выполнялось слияние определённых файлов?
Подскажите, пожалуйста, по следующему моменту.
В репозитории есть ветки dev и master, которые предназначены для dev/prod окружения. В каждой из них есть пара конфигурационных файлов, которые для каждого окружения свои и при выполнении merge нужно, чтобы в каждой ветке сохранялись правильные конфиги.
В интернете/чатгпт на такой запрос в основном выдаётся информация по .gitattributes и merge=ours, но в данном случае оно не работает, т.к. как я понимаю, чтобы merge=ours сработал, нужно, чтобы создался конфликт, а файлы конфигов меняться будут довольно редко и конфликтов не происходит (хотя возможно, что я ошибаюсь, но способ всё равно не работает. Возможно, конечно, что я что-то делаю не так, но вроде всё правильно).
Также видел мнение, что конфигурационных файлов вообще в репозитории быть не должно, они должны храниться где-то отдельно. В моём случае это, конечно, можно организовать, но будет не удобно. Гораздо проще будет, если оно всё будет храниться в репозитории.
В общем, подскажите, пожалуйста, возможно ли это реализовать или я зря мучаюсь и просто не нужно хранить конфиги в репозитории?
Два варианта:
1. Файлы конфигов добавляются в .gitignore и настраиваются в каждом окружении отдельно.
2. Настраиваете CI/CD и при выполнении задания копируете (создаете) нужный конфиг в зависимости от окружения.
гитлаб указан в тегах верно?
поместите эти параметры в CICD переменные (поддерживаются в том числе файлы, а так же маскировка секретов), лимитировав их использование конкретным ENV-ом https://docs.gitlab.com/ci/environments/
ну и укажите в деплой шагах ENV-ы (можно брать из имени бранча динамически)
хранить в репе все таки не стоит
HydrogenOxyde, ну как бы это логично сделать, чтобы не было лишнего влияния не-прод сред на прод
как еще вариант - если у вас есть хранилище KV или секретов (типа Consul и Vault) - брать все параметры запуска динамически на старте приложения. Но, как всегда, есть нюансы с таким подходом
переделать статическое хранение в репе на статическое же хранение в CICD переменных и немного (вроде бы, не видел вашего пайплайна) изменить пайплайн для вас будет более легким способом и сделать более правильно и указанную в вопросе проблему решить
Евгений Хлебников, да, так, наверное, будет правильнее, точки зрения правильного подхода. Но в случае необходимости изменения файлов я уже не смогу сделать это сам, нужно будет обращаться к девопсам, растёт, так сказать, бюрократический фактор (особенности работы в большой компании). Собственно, поэтому и искал возможность оставить эти файлы в репе. Тем более, там никаких секретных секретов нет, просто немного настроек
помнится, когда у меня начинали забирать full admin в гитлабе (просто с нашего проекта начиналось его внедрение и сначала мы его менеджили - затем управление ушло в IT команду) я обсуждал создание кастомных ролей, поскольку управление CICD переменными конкретного проекта должно лежать не на команде, которая управляет гитлабом, а на команде управляющей этим конкретным проектом
настроить управление чисто CICD Variables в кастомной роли для разработчиков вполне можно, чтобы не плодить бюрократии
Храните просто оба файла конфигурации. Либо создайте сабмодуль, в которой создайте ветки для каждого конфига, которые не будут сливаться друг с другом. Либо храните в конфигурации значения и для дева и для прода. Например для прода с префисом PROD_
Есть в git понятия git attributes и соответственно файл . gitattribute в котором и можно заблокировать изменения файлов при MR.
Приведенные выше сценарии не всегда подходят:
.gitignore - не даст вам контролировать изменения даже в рамках одного контура
В CI/CD vars - тут вообще нет не какого контроля изменений этих конфигов.
Вынести конфиги из репы не всегда возможно/удобно.
