Git *

Запуск GitLab Runner в Yandex Cloud Serverless Containers

Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.

GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.

Раннер работает в разных окружениях:

• на общих серверах GitLab (shared runners);

• на выделенных VM;

• в K8s‑кластере.

В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.

Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.

Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:

• оплата за время

• масштабирование за секунды

• изоляция выполнения

• отсутствие инфраструктурной рутины

Архитектура

GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.

Пришла задача — раннер выбирает executor:

• shell — job выполняется в текущем окружении

• docker — под job создаётся отдельный контейнер со всеми зависимостями

Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.

Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:

• запускает раннер;

• получает информацию о задаче;

• выполняет её и возвращает результат в GitLab.

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

GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:

1. GitLab отправляет вебхук.

2. Платформа проверяет авторизацию и сразу отвечает 202 Accepted.

3. Обработка выполняется асинхронно в фоне.

Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.

GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.

Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.

Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.

Используемые возможности Serverless Containers

1. Эфемерные диски до 10 ГБ на контейнер

2. Асинхронный запуск контейнеров

3. Таймаут выполнения до 1 часа

4. Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.

Важные особенности serverless‑подхода

• Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.

• Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.

• Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.

• Ограничение по диску: до 10 ГБ.

Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.

• Руководство

• Исходный код

Друзья, классная новость! Мы с коллегами из GitVerse закончили разработку интеграции! 

Теперь в Gramax можно подключить GitVerse в качестве хранилища. Работает в лучшем виде: клонирование, синхронизация, коммит, пуш — все как и должно быть ✨

Это была масштабная и интересная работа: мы вместе анализировали API, чтобы получилось максимально удобно. Потому будем очень рады увидеть ваши плюсики!

Gramax — Open Source-платформа для работы с документацией в подходе Docs as Code. GitVerse — AI-first платформа для работы с кодом.

💥 Новое в Gramax 💥

Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией. За последние 3 месяца мы сделали много новых полезных функций, коротко расскажу о самых важных.

• Интеграция с GitVerse. Теперь в качестве хранилища можно использовать GitVerse. Как подключить GitVerse к Gramax читайте в статье.

• Поддержка Gitea. Также добавили поддержку Gitea: доступно подключение в качестве хранилища и использование всех возможностей Gramax.

• Экспорт в PDF и DOCX в собственных стилях. Можно настроить вид документа: добавить титульную страницу, оглавление, номера заголовков, собственные шрифты и отступы и так далее. Для DOCX — с помощью стилей, для PDF — с помощью CSS. Применяется при экспорте из приложения, портала документации и в CI/CD.

• Новые возможности для статического сайта. В новой версии Gramax CLI поддерживается: развертывание в поддиректорию, кастомная страница 404, настройка стилей, индексации, сбора метрик и логотипа.

• Предпросмотр загруженных файлов. Теперь при клике на загруженный файл в статье открывается окно предпросмотра. Отображаются файлы форматов DOCX и PDF. Остальные форматы — скачиваются.

• Улучшения поиска.

  • Новое ранжирование. Больший вес дается результатам, в которых искомое слово содержится в названии статьи или в одном из заголовков.

  • Переход к поисковой фразе. После клика на результат поиска статья откроется на том фрагменте, в котором есть поисковый запрос.

  • Настройка поисковой выдачи. Для статей можно указать поисковые запросы: если в поиске ввести один из них, статья отобразится выше остальных.

  • Поиск по свойствам в приложении. Если на статьях установлены свойства — в поисковой строке можно отфильтровать по ним.

  • Улучшение внешнего вида. Теперь в результатах есть указание на каталог, в котором содержится запрос. А также отображается иерархия заголовков в статье.

• Улучшения Gramax Enterprise Server.

  • Разворачивание с помощью Helm. Добавили новый способ разворачивания Gramax Enterprise Server в Kubernetes.

  • Тестирование знаний. Реализовали модуль проверки знаний читателей: в статью можно добавить тест с разными типами вопросов. После прохождения статистика пользователей отобразится в панели администрирования.

  • Поиск по вложенным файлам. Теперь поиск учитывает не только контент статьи, но и контент из PDF и DOCX-файлов.

О других изменениях читайте в Release Notes.

«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.

Участвовать просто:

• разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.

• делится кодом и вдохновляться чужими разработками.

Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».

Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.

7 полезных плагинов для фронтенд-разработки в VS Code!

Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.

1. ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠

2. Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊

3. Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍

4. DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦

5. GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.

6. NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳

7. SonarQube — анализирует качество кода, ищет уязвимости. 🔐

Установите эти плагины и сделайте свою работу ещё эффективнее! 💻

Быстрые сборки с функцией Rollback в Amvera Cloud

Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.

Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!

Стало легче откатывать приложение, в случае ошибок.

Подключить быстрые сборки можно в разделе проекта «Контроль версий».

Новые сборки

1. Быстрее старых до 10 раз.

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

Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.

Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест. 

⚙️ Настройка разных пользователей Git для разных проектов

В домашней директории есть три папки:

- ~/ProjectHome/
- ~/ProjectWork/
- ~/ProjectOther/

В каждой нужно работать от своего пользователя:

- userHome
- userWork
- userOther

Чтобы работать в каждом проекте без дополнительных переключений, нужно сделать следующее:
1. Добавить настройки в .gitconfig

Откройте файл ~/.gitconfig и добавьте в него:

[includeIf "gitdir:~/ProjectHome/"]
path = ~/.gitconfig-home
[includeIf "gitdir:~/ProjectWork/"]
path = ~/.gitconfig-work
[includeIf "gitdir:~/ProjectOther/"]
path = ~/.gitconfig-other

2. Создать отдельные конфиги для каждого пользователя
Создайте в домашней директории три файла:

- ~/.gitconfig-home
- ~/.gitconfig-work
- ~/.gitconfig-other

3. Прописать пользователя и SSH-ключ в каждом конфиге
Пример содержимого для ~/.gitconfig-home:

[user]
name = userHome
email =userHome@mail.ru
[core]
sshCommand = "ssh -i ~/.ssh/id_userHome_ed25519"

Аналогично создайте .gitconfig-work и .gitconfig-other, указав соответствующего пользователя, почту и путь к ключу.

⚠️ При этом из основного .gitconfig нужно удалить секции [user] и [core.sshCommand], чтобы не было конфликтов.

4. Указать правильный remote для каждого проекта в своей папке

Для проектов в ~/ProjectHome/:
git remote set-url origin git@github.com:userHome/ProjectHome.git

Для проектов в ~/ProjectWork/:
git remote set-url origin git@github.com:userWork/ProjectWork.git

Для проектов в ~/ProjectOther/:
git remote set-url origin git@github.com:userOther/ProjectOther.git


💡 ProjectHome.git, ProjectWork.git, ProjectOther.git - это просто примеры названий репозиториев, они могут быть любыми.

📌 Важно: эти команды нужно выполнять для каждого проекта отдельно, а не один раз для всей папки.

5. Разместить SSH-ключи

В директории ~/.ssh/ должны находиться три приватных ключа, которые вы сгенерировали для каждого пользователя.

Например:
- id_userHome_ed25519
- id_userWork_ed25519
- id_userOther_ed25519

Убедитесь, что имя ключа соответствует указанному в параметре sshCommand внутри соответствующего .gitconfig-*

✅ Результат

Теперь можно:
- Открыть в редакторе любой проект из этих папок.
- Работать, делать коммиты и пушить - без ручного переключения пользователя или ключа.
- Открыть сразу несколько проектов из разных папок - всё будет работать корректно.

Можно добавить и больше папок с пользователями - принцип остаётся тем же.

Добавлю еще вариант, подходит для Gitlab:
https://qna.habr.com/q/1400592

Автоматическое добавление номера задачи в коммит

Привет, Хабр! 👋
Хочу поделиться небольшой, но полезной фичей, которая упростила мне жизнь при оформлении коммитов.

В своей работе я придерживаюсь структурированного подхода к именованию веток и сообщений коммитов. Подробнее об этом можно почитать здесь:
📎 https://habr.com/ru/articles/820547/

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

Почему это удобно?

Указание номера задачи позволяет быстро понять, какие именно тикеты попадают в релиз. Особенно это помогает при ревью и при деплое.

Пример структуры ветки:

feat/dev-123_filter или fix/dev-432_filter

Сообщения коммитов я пишу в следующем формате:

dev-123 | настроил сортировку в фильтре

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

Скрипт prepare-commit-msg

#!/bin/sh

COMMIT_MSG_FILE=".git/COMMIT_EDITMSG"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)

if echo "$BRANCH_NAME" | grep -qE 'dev-[0-9]+'; then
  TASK_ID=$(echo "$BRANCH_NAME" | grep -oE 'dev-[0-9]+')

  if ! grep -q "$TASK_ID" "$COMMIT_MSG_FILE"; then
    sed -i.bak "1s/^/$TASK_ID | /" "$COMMIT_MSG_FILE"
    rm -f "$COMMIT_MSG_FILE.bak"
  fi
fi

Скрипт нужно сохранить как .git/hooks/prepare-commit-msg и сделать исполняемым:

chmod +x .git/hooks/prepare-commit-msg

Как это работает?

• COMMIT_MSG_FILE — путь до файла, в который Git записывает текст коммита.

• BRANCH_NAME — название текущей ветки.

• Сначала проверяется, есть ли в названии ветки номер задачи (dev-123).

• Если он найден и ещё не указан в коммите — скрипт добавляет его в начало первой строки сообщения.

Таким образом, ваш коммит автоматически будет выглядеть так:

dev-123 | добавил пагинацию в список товаров

Вроде мелочь, а приятно — экономит время и упрощает навигацию по истории коммитов.

Если будет интересно — это и другие полезные скрипты, на моём GitHub

https://github.com/prog-time

Спасибо за внимание! ✌️

Новая версия Gramax!

• Сравнение ревизий. Можно сравнить текущую версию каталога с одной из предыдущих.

• Экспорт в корпоративных шаблонах DOCX. Добавили возможность загрузить корпоративный шаблон DOCX и экспортировать статьи и каталоги в этом шаблоне.

• Избранное. Каталоги и статьи можно пометить как Избранные для быстрой навигации. Это доступно как в приложении, так и на портале документации.

• Связанные статьи. В меню статьи можно просмотреть: куда ссылается статья и какие статьи ссылаются на нее.

Об этих и других изменениях читайте в Release Notes 🔥

Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков

Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.

Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.

Инструменты безопасности

На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.

По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.

Чат‑режим в SourceCraft Code Assistant

ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.

Зеркалирование и бесшовная миграция

Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.

Также появился федеративный доступ к платформе для компаний — авторизация через SSO.

Публичный API

Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.

Правила работы с ИТ‑проектами

В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.

Опенсорс

Появился анонимный доступ к публичным репозиториям платформы. Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.

Удобство работы с кодом

Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.

Автоматизация CI/CD‑процессов

Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.

Packages

Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.

Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.

В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).

Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud

Привязка репозиториев GitHub, GitLab, BitBucket вызывала у наших пользователей затруднения, и мы обещали упростить процесс.

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

Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.

Подробная инструкция по подключению доступна по ссылке.

Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.

Обойдемся и без Terraform: внедряем GitOps-подход для виртуальных машин

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:

1. В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.

2. На основе этих файлов формируются конфигурации для новых ВМ.

3. Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.

4. После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.

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

В своей статье Кирилл Яшин рассказывает, как с нуля реализовать такой подход к виртуальным машинам, используя провайдеры для работы с OpenStack и DNS.

Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault

Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.

Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.

Какая вылезла проблема

Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: airflow
 labels:
   app.kubernetes.io/name: airflow
   app.kubernetes.io/component: airflow
 namespace: argocd
 finalizers:
   - resources-finalizer.argocd.argoproj.io
spec:
 project: default
 destination:
   namespace: some-namespace
   name: cluster
 source:
   repoURL: "airflow_repo_url"
   targetRevision: "revision"
   chart: airflow
   plugin:
     name: argocd-vault-plugin-helm
     env:
       - name: HELM_VALUES
         value: |
             ...
             metadataConnection:
               user: user
               pass: <path:path/to/airflow/secrets#postgres_password>
               protocol: postgresql
               host: postgres.db.url
               port: 5432
               db: airflow_db
               sslmode: prefer
             ...
   
 syncPolicy:
   automated:
     prune: true
     selfHeal: true
   syncOptions:
     - Validate=true
     - CreateNamespace=true

Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.

В чем итоге была проблем и как Антон с ней справился, читайте в статье →

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.

В статье даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.

Pre-commit — must have утилита любого проекта

Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество:
— разные куски кода по-разному отформатированы;
— импорты в файлах никак не структурированы;
— используются вперемешку синтаксис старых и новых версий питона;
— где-то видны зачатки использования типов, но не везде;
— где-то docstring есть, где-то нет;
Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.

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

Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.

В DevFM пишу о полезном для разработчика.

Для тех, кто хочет распилить монорепу на подмодули или уже сделал это. Задача со звёздочкой.

Дано: в репозитории около 50 подмодулей,  текущие ветки у них имеют разные названия. Джун Вася создал в каждом подмодуле новую ветку и внёс минорные правки. Чтобы провести ревью, миддл Серёжа получил Васины изменения, переключил ветки родительского репозитория и выполнил команду:

git submodule update --init --recursive

После ревью Вася пошёл исправлять замечания, а Серёжа вернулся к разработке своей фичи, вот только подмодули теперь в состоянии head detached.

Вопрос: как быстро подгорит у программистов из-за необходимости выставлять подмодули из состояния head detached в соответствующие feature-ветки, если процесс повторять?

Решение: использовать команду:

git submodule foreach --recursive 'git name-rev --name-only $sha1 | xargs git checkout'

По хешу команда найдёт указатель и на него переключится. Если есть несколько указателей для текущего коммита, будет выбрано имя ветки первое по алфавиту.
Если на текущий коммит подмодуля никакая ветка не указывает, получим head detached. Рекурсивно (если у подмодулей есть подмодули) тоже работает.

Ответ: так и живём.

Всем DevOps! Автоматизация проверки одобрений merge requests с помощью GitLab CI/CD и GitLab API — это классный способ без лишних затрат оптимизировать процесс управления кодом в вашей команде.

Наш DevOps-инженер Виктор рассказал, как он смог настроить approve rules для merge request в бесплатной версии GitLab CE.

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

💻 Если ещё не читали — тогда вам сюда!

Российские IT-компании готовятся к массовому отключению иностранных сервисов. Большинство привычных сервисов могу скоро просто отвалиться.

Все из-за санкций Минфина США, которые запрещают предоставление услуг в сфере программного обеспечения, IT-консультирования и проектирования на территории РФ.

Российские IT-конторы, соответственно, вынуждены искать бесплатные альтернативы с открытым кодом, на которые не распространяется запрет, а облачные хранилища теперь — только российские.

Кстати, как я смотрю, Сбер очень активно к этому готовился. У них и IDE на базе PyCharm— GIGA IDE, и гит-платформа GitVerse (полный аналог GitHub), и куча еще всего.

Я пока не особо тестил GIGA IDE, т.к. полностью перешел на майковский VS Code. Но он на базе комьюнити версии, только с разными плюшками и ИИ. А гит-платформа выглядит симпатично, ничего больше сказать не могу. Вероятно, всё это имеет очень хороший смысл, если трудишься полностью в их экосистеме.

В любом случае, молодцы, что предоставляют альтернативу.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.46.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 746 изменений,
подготовленных при участии 96 разработчиков, из которых 31 впервые
участвуют в разработке.

Основные изменения:

• добавлена экспериментальная поддержка нового вида битовых карт — «pseudo‑merge reachability bitmap», в которых в отличие от структуры «reachability bitmap» данные о наборах объектов, имеющих отношение к коммитам, хранятся в привязке сразу к нескольким коммитам.

• реализован интерфейс командной строки для команды «git config», в котором вместо разрозненных опций для просмотра, переименования и удаления настроек и секций, таких как «‑get», «‑get‑all», «‑unset» и «‑remove‑section», предложен набор отдельных субкоманд.

• В команду git добавлена опция «‑no‑advice», отключающая все сообщения с рекомендациями и подсказками, что может оказаться полезным для предотвращения забивания лога лишней информацией при автоматизированном вызове git.