😀😃😄😁😆

🔧 Утилиты: #utils
💳 Таблицы: #sheets
⚙ Скрипты: #bash
🎙 Мониторинг: #monitoring
🤔 Отладка: #debug
🎃 Линукс: #linux
✉️ Nginx: #nginx
📦 GIT: #git
📊 Mysql: #mysql
📱 Сервисы: #services
🔄 Девопс: #devops
🛡 Безопасность: #security
👻 Игры: #games
🌐 Сети: #networks
💬 Будни: #рабочиебудни

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

Сейчас автоматизируем
ㅤ
Про shellcheck я писал отдельный пост. Короче он у тебя должен быть установлен.

Дальше создаем файл .git/hooks/pre-commit в репозитории, в котором нужно запускать проверку и пишем в него:

#!/bin/bash

bash_scripts=$(find . -name "*.sh")

for script in $bash_scripts; do
    shellcheck "$script"
    if [ $? -ne 0 ]; then
        echo "Shellcheck failed on $script. Commit aborted."
        exit 1
    fi
done

exit 0

Хуй знает, работает этот код или нет, я давно им не пользовался, главное тут концепт.

Делаем это исполняемым:

chmod +x .git/hooks/pre-commit

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

По началу это напряжно, но потом понимаешь что у тебя уже вырабатывается какой-то кодстайл и ты не можешь распиздяйничать.

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

Помню в компании была подобная штука на проверку puppet кода, пиздец, я там орал как белуга не понимая что эта тварь от меня хочет. По итогу когда я возглавил отдел, выкосил это дермище вместе с puppet.

Бонусом адаптация под проверку ansible плейбуков:

#!/bin/bash

playbooks=$(find . -name "*.yml" -o -name "*.yaml")

for playbook in $playbooks; do
    ansible-lint "$playbook"
    if [ $? -ne 0 ]; then
        echo "ansible-lint failed on $playbook. Commit aborted."
        exit 1
    fi
done

exit 0

В зависимостях — нужно установить ansible-lint.

С помощью pre-commit можешь любую хуйню замутить и усложнять себе жизнь в геометрической прогрессии, А вообще pre-commit нахуй не нужен, он помещает тебя в рамки и ты теряешь свободу в творчестве.

Пользуйтесь.

tags: #bash #git
—
🔔 @bashdays

Как правильно хранить тяжелые файлы гит репах? Например, бинарники или что-то подобное.
ㅤ
Ответ очевидный и правильный — никак! В гитлабах/гитхаба/битбакетах установлены лимиты на размер отдельных файлов. Там что-то вроде 50 метров на файл дается.

В принципе можно уложиться. Но нахуй надо. Прикинь у тебя пайплайн вытягивает репу размером с 10 гигабайт. И так каждую сборку. Гит репа должна быть тощей и дрищёвой.

А всё тяжелое будь бобр-добр храни в s3 либо на других решениях.

НО если очень хочется прям в гите держать. Для этого существует GIT LFS. Дословно — Large File Storage (дохуя большое файловой хранилище).

У LFS уже свои лимиты в отличие от нативного git репозитория. И это LFS включен из коробки в гитлабах/гитхаба/битбакетах. Там уже размер файла может быть 1 гигабайт или что-то вроде того.

В gitea тоже можно LFS через конфиг включить:

[server]  
LFS_START_SERVER = true  
LFS_ALLOW_PURE_SSH = true
  
[lfs]   
PATH = /home/gitea/data/lfs

Как этим пользоваться?

Ставим к себе на машину:

apt-get install git-lfs
brew install git-lfs

Переходим в свой гит репозиторий и инициализируем:

cd /home/user/linuxfactory/infra
git lfs install

В папке /infra/roles/node_exporter/files у меня лежит бинарник node_exporter который весит 100 мегабайт

На самом деле я хуй знает сколько он весит, это для примера.

Помечаем его:

cd /infra/roles/node_exporter/files
git lfs track "node_exporter"

После этого в папке files появится файл .gitattributes. Это правила для этого файла, которые указывают чтобы node_exporter улетал в LFS.

Внутри этот файл выглядит так:

node_exporter filter=lfs diff=lfs merge=lfs -text

И по итогу бинарник в репе станет ссылкой на настоящий бинарник в LFS.

А еще можно вайлдкардами трекать:

git lfs track "*.jpg"

Ну а дальше, как обычно:

git add .
git commit -m "add lfs for node_exporter"
git push

Всё! Теперь твой большой файл аккуратно лежит в LFS, а в самом гит репозитории осталась лишь ссылка которая на этот файл ссылается.

Мне тут пришлось партнерских постов на эту неделю понабрать, реинвестируем в развитие @gitgate, так что рекомендую включить баннерную слепоту и сильно не триггериться. Спасибо за понимание!

Чтиво: про LFS можешь глянуть еще тут и тут.

tags: #git #devops
—
🔔 @bashdays➡️ @gitgate

Как я понял много кто за гит не шарит, опять же судя по ОЧЕНЬ частым вопросам в LF. Хотя очевидные вещи для одного, не всегда очевидны для другого.

Поэтому давай закрывать эти боли. Будет несколько серий постов, банально, но полезно. Пройдем максимально просто и быстро. Если чо непонятно пиши в комменты, будем разбираться.

Думал в рамках закрытого интенсива сделать, но пусть будет бесплатно.
ㅤ
Ну и первая проблема:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <user@dev.>) not allowed

Не устану повторять — читай то, что тебе пишут!

Эта штука появляется в момент команды git commit.

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

То есть гит не знает от чьего имени оправлять коммит в репозиторий.

Как решать?

Ну оно тебе явно уже написало какие команды нужно забить. А забить надо пару строк:

  git config --global user.email "hello@devopsina.ru"
  git config --global user.name "Roman Shubin"

Всё, теперь коммит подпишется и ошибка уйдет. Глобальные настройки обычно лежат в файле ~/.gitconfig

Ну дак оно же глобально прописалось для всех реп??

Конечно, но это можно изменять в конфиге самой репы. То есть допустим у меня есть 2 репы:

1. BashDays
2. LinuxFactory

В первом случае я хочу подписывать и отправлять коммиты как Roman Shubin, а во втором как Harbor Whore.

Сейчас на глобальном уровне в обоих случаях будет Roman Shubin.

Чтобы это пофиксить. Открываем нужную нам гит репу на своей машине, пиздуем в папку .git и открываем на редактирование файл config.

Ну и в него добавляем секцию user.

[user]
    name = Roman Shubin
    email = hello@devopsina.ru

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

Если руками в падлу писать, выполняем команды:

git config user.email "hello@devopsina.ru"
git config user.name "Roman Shubin"

Тут отсутствует ключик --global.

Ну и чтобы посмотреть кем подпишется коммит, есть команда:

git config --list --show-origin

Находясь в папке с репой, она выведет всю необходимую информацию. Порой очень полезно предварительно проверить, перед пушем в репу.

Ну и скучная, но важная теория:

- Если вы используете GitHub, GitLab или другую платформу, и хотите, чтобы ваши коммиты были связаны с вашим аккаунтом, то email, указанный в Git, должен совпадать с email, привязанным к вашему аккаунту на этой платформе. Это нужно для того, чтобы платформа могла корректно отображать ваши коммиты в вашем профиле.

- Если email не совпадает, коммиты все равно будут отправлены, но они не будут автоматически связаны с вашим аккаунтом на платформе.

Такие дела. Видишь, не все так сложно как ты думаешь. Завтра рассмотрим еще очень важные вещи, от которых жопа обычно горит на начальных этапах.

tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate