Git има много полезни и различни кукички
Когато сме изправени пред задачата да променим кодовата база, например в хранилище на Github, за да изградим/рестартираме някое приложение в някои от нашите среди, първото нещо, което идва на ум като възможен тригер за такова повторно изграждане, е механизмът за уеб закачка, предоставен от същия github: когато се случи събитие с нашето отдалечено хранилище (тъй като се появява нов ангажимент в някои от неговите проследени клонове), github активира съответния уеб закача и "изтегля" услугата, посочена в нейните настройки, което ще започне процеса на повторно изграждане / рестартиране на нашето приложение. Това е стандартен широко използван и прост механизъм за такива случаи, всеки го прави и всичко това...
Но какво ще стане, ако нашето приложение живее на хост, до който github няма достъп по някаква причина? Например, хостът в затворена мрежа ли е или зад NAT и не е достъпен от интернет? В този случай можете да използвате механизма за локална кука на самия Git, за който, както се оказва, много малко хора знаят дори сред тези, които използват Git от доста дълго време.
Когато създаваме локално хранилище (инициализираме празно, клонираме отдалечено, . ), тогава в папката .git, която е в корена му, или в самия корен, ако е голо хранилище, има папка с кукички. След като хранилището бъде инициализирано, шаблоните за кука за различни събития се съхраняват в тази папка, като например: след сливане, след получаване, след актуализиране и т.н.
Пълно описание на поддържаните събития за кукички можете да намерите например тук.
Ще използваме този механизъм и ще внедрим проста схема за внедряване за нашето мизерно приложение.
Ще ни трябват две локални хранилища. Нека ги създадем, например, според посочените пътища:
1. /opt/repo-dev/example-repo/ 2. /opt/repo-remote.git/
Първото хранилище е клонинг на нашето отдалечено хранилище за примерни репо в github. Вторият е голо хранилище, копие на първото, което ще ни служи изключително за обработка на събитието след актуализиране, когато актуализациите се появят в отдалеченото хранилище. И така, как да приложим това?
Схемата е много проста (ако приемем, че наблюдаваме тестовия клон и нашето приложение е node.js, управлявано от pm2 мениджъра):
1. Периодично актуализирайте първото локално хранилище до състояние, което напълно съответства на състоянието на отдалеченото хранилище. 2. Актуализирайте второто от първото локално хранилище. 3. Веднага след като HEAD се премести - появи се нов ангажимент - куката за след актуализиране ще бъде активирана във второто хранилище, което се изпълнява, когато се появят промени в хранилището, и което ще извърши необходимите действия за повторно изграждане и рестартиране на приложението.
За целта правим следното:
1. В първото локално хранилище добавете дистанционно - второто локално хранилище:
Сега можем да git push от първото локално хранилище към второто.
2. В папката /opt/repo-remote.git/hooks/ създайте файл след актуализиране и го направете изпълним:
Това е нормален шел скрипт, но според вътрешната конвенция на Gitбез разширението .sh! Нека добавим някои команди към него:
Какво прави скриптът? Първо, той просто качва работното дърво на нашето голо хранилище в папката с нашето работещо приложение и след това възстановява зависимостите и рестартира pm2 услугите. Както виждате, няма магия.
3. Настройте cron, който на всеки n минути ще актуализира първото хранилище от дистанционното:
Така. сега нашият хост ще бъде редовен инициатор на проверкаотдалечено хранилище - появиха ли се някакви актуализации там?
Моля, обърнете внимание, че актуализираме локалното хранилище не чрез git pull, а чрез git reset --hard. Това се прави, за да се елиминира необходимостта от сливане с определено съдържание на следващия комит - ние правим локалното хранилище пълно копие на отдалеченото.
4. Веднага след синхронизирането на първото локално хранилище с отдалеченото, ние натискаме всички промени в нашето псевдо-отдалечено второ локално хранилище:
Това е всичко. Веднага след като нашето псевдо-отдалечено локално хранилище получи различни от нула промени, Git изтегля своята кука след актуализиране, която изпълнява подходящия скрипт. И получаваме проста работеща push-to-deploy схема, която при желание може да бъде допълнително подобрена в съответствие с нашите нужди.
„Защо да се занимаваме с такава несмилаема чудовищна схема?!“ - ти питаш. Първоначално зададох същия въпрос, но се оказа, че със съществуващия списък с Git кукички, това е единственият начин, по който можем да извикаме необходимата обработка на всяка актуализация на нашия клон в отдалеченото хранилище. Кукичката след актуализиране, от която се нуждаем, е проектирана да работи в отдалечено хранилище (а някои от куките са проектирани да работят в локално хранилище). И ние симулирахме това псевдо-отдалечено хранилище по такъв не много елегантен начин. Може би скоро ще има по-удобна кука, която работи локално, и схемата може да бъде опростена. Но засега така.
Ще се радвам на всякакви коментари и уточнения по същество.
Приятен ден на всички!
Можете да помогнете и да прехвърлите средства за развитието на сайта