#git #githooks #automated-deployment
Вопрос:
У меня возникли проблемы с тем, чтобы заставить мерзавца игнорировать мой wp-config.php
файл при развертывании. Я настроил автоматическое развертывание с помощью git (это действительно отличный инструмент, если вы об этом не знаете, вы можете прочитать об этом здесь — вам не нужно использовать хостинг kinsta, как указано в статье, хотя ваша структура файлов может отличаться).
Но каждый раз, когда я нажимаю на изменения, он перезаписывает мой wp-config.php
файл, вызывая ошибку базы данных на сайте. Это происходит потому, что крючок git, используемый для развертывания, вводит изменения, а затем проверяет любые локальные изменения. Поскольку это промежуточный сайт, он использует репо из производства, но имеет другие значения wp-config.php
, чтобы подключиться к своей собственной базе данных.
То, что я пробовал до сих пор:
- фиксация изменений в wp-конфигурации на промежуточном сервере, чтобы он не был проверен крючком git
- добавление
wp-config.php
.gitignore
(я должен был сделать это изначально) на промежуточный сервер - добавление
wp-config.php
.gitignore
(я должен был сделать это изначально) в разработку и переход к этапу - добавление строки в
post-receive
крючок для проверки измененийwp-config.php
после выполнения развертывания
Вот мой post-receive
файл крючка (имя клиента заменено на XXXXX):
#!/bin/bash
TARGET="/www/XXXXX_975/public"
GIT_DIR="/www/XXXXX_975/private/XXXXX.git"
BRANCH="master"
while read oldrev newrev ref
do
# only checking out the master (or whatever branch you would like to deploy)
if [[ $ref = refs/heads/$BRANCH ]];
then
echo "Ref $ref received. Deploying ${BRANCH} branch to staging..."
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
git checkout /www/XXXXX_975/public/wp-config.php
else
echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
fi
done
Сайт находится в public
каталоге. Репозиторий находится в другом каталоге private
, чтобы не быть перезаписанным развертываниями.
Это веб-сайт WordPress, размещенный на Kinsta. Дайте мне знать, если я забыл включить какую-либо информацию.
Спасибо!
Комментарии:
1. Ваш
wp-config.php
файл зарегистрирован в хранилище?2. Привет @bk2204! Не могли бы вы уточнить свой вопрос?
3. Является
wp-config.php
ли файл, который вы видите, перезаписанной частью проверенных файлов в репозитории (то есть он указан как частьgit ls-files
), или это что-то, что находится в том же каталоге и не отслеживается Git?4. Да, это отслеживается мерзавцем. Я упомянул, что задним числом добавил его в gitignore, но он отслеживается git.
5. Если вы уже добавили его
.gitignore
, сделайте резервную копию файлов конфигурации на серверах. После этого удалите файлы из git-трекинга с помощьюgit rm
. Затем разверните эту фиксацию (которая удалит файлы с сервера!) и восстановите файлы вручную из резервной копии. После того, как вы это сделаете, git не будет трогать эти файлы в будущем (потому что они больше не отслеживаются, а также.gitignore
«d»)
Ответ №1:
Когда вы проверяете ревизию без указания конкретных путей, Git всегда перезапишет файлы рабочего дерева с файлами в редакции, и этого невозможно избежать. В вашем конкретном случае вы пытаетесь игнорировать изменения в отслеживаемом файле, что, как объясняется в часто задаваемых вопросах Git, невозможно сделать.
Поскольку вы поняли, что этот файл не должен был отслеживаться в первую очередь и его следовало игнорировать, вы можете просто сделать git rm --cached wp-config.php
, а затем зафиксировать, чтобы удалить его из репозитория. Затем файл будет удален, когда вы отправите его на удаленные серверы, но в будущем у вас будет преимущество в том, что вы сможете настроить пользовательскую версию для каждого из промежуточных и производственных серверов в будущем, и Git оставит его в покое.
Комментарии:
1. Редактирование моего комментария, потому что я неправильно понял, что сказал @Jay выше , Приведет ли это к каким-либо простоям? Есть ли способ сделать это без простоев (по крайней мере, для производства)?
2. Вы можете отредактировать сценарий развертывания, чтобы скопировать файл в сторону, затем выполнить проверку, а затем скопировать его обратно. Это приведет к небольшому времени простоя (возможно, на секунду), но оно не должно быть существенным.