Котлеги, привет. Сегодня без длинных постов - но я не могу не рассказать про https://github.com/ripienaar/free-for-dev.
Это просто клад - тысячи бесплатных сервисов и инструментов для ойтишников: хостинги, CI/CD, мониторинг, базы данных и многое другое. И самое главное что не триалы, а реально бесплатные тарифы (с ограничениями, но без внезапных счетов).
Если вы запускаете pet-проект, MVP или просто хотите сэкономить на инфраструктуре - must-have в закладках.
P.S. Если вы уже что-то используете оттуда - напишите, что зашло. 🤘
#tools
Это просто клад - тысячи бесплатных сервисов и инструментов для ойтишников: хостинги, CI/CD, мониторинг, базы данных и многое другое. И самое главное что не триалы, а реально бесплатные тарифы (с ограничениями, но без внезапных счетов).
Если вы запускаете pet-проект, MVP или просто хотите сэкономить на инфраструктуре - must-have в закладках.
P.S. Если вы уже что-то используете оттуда - напишите, что зашло. 🤘
#tools
GitHub
GitHub - ripienaar/free-for-dev: A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev
A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev - ripienaar/free-for-dev
👍9👀8❤3🔥1
Пока я готовлю несколько классных статьей (спойлер: про grafana и про мониторинг CPU), решил сюда выложить историю легендарной операционной системы, которая была уже опубликована мной на хабре, но почему то не пошла сюда. Заваривайте чай, берите печеньки и наслаждайтесь - будет интересно.
А вы знали что операционная система OS/2 должна была стать революцией, а стала легендой? В этот прекрасный воскресный вечер предлагаю вам вместе со мной вернуться в прошлое и вспомнить или, возможно, узнать для себя что то новое об истории OS/2. [image01]
В начале 1980-х IBM была лидером в производстве компьютерного железа (аппаратного обеспечения), но у неё не было опыта в создании операционных систем для массового пользователя. Она искала партнёра, который бы помог разработать простую и удобную ОС для нового IBM PC. [image02]
IBM стремилась как можно быстрее закрепить своё лидерство на рынке персональных компьютеров. Для этого нужна была ОС, способная превзойти MS-DOS и конкурировать с появляющимися графическими системами (Macintosh от Apple).
Партнёрство с Microsoft выглядело самым быстрым и надёжным способом добиться этой цели. И вот в 1985 году IBM и Microsoft объявили о партнёрстве по созданию новой ОС - OS/2. Она должна была прийти на смену DOS. Microsoft тогда верила: “Windows - это временный шаг. Будущее за OS/2”.
Windows 1.0 и 2.0 были по сути надстройками над MS-DOS, а не полноценными ОС. Они не имели защищённой памяти и серьёзных архитектурных решений. В глазах Microsoft Windows была временным шагом, который просто поможет плавно перевести пользователей с текстового интерфейса на графический, пока не выйдет OS/2. [image03]
OS/2 1.0 вышла в декабре 1987. Без GUI, только текстовый интерфейс. Зато: поддержка 80286, многозадачность, управление памятью до 16 МБ. Но не запускала Windows-программы. [image04]
IBM и Microsoft делили обязанности: IBM работала над Presentation Manager (графикой), Microsoft - над ядром и API. В итоге GUI OS/2 1.1 стал прообразом будущего Windows 3.x. Presentation Manager был амбициозным: поддержка окон, пропорциональных шрифтов, горячих клавиш. А позже Microsoft даже выпустила Word и Excel под OS/2. [image05]
Но у OS/2 была проблема - она требовала 2 МБ ОЗУ, а память в 1989 году это очень дорого. Windows 3.0, вышедшая в 1990, запускалась на 640 КБ и стала коммерчески успешной. Низкие системные требования, доступная цена, лёгкая установка и большое количество популярных приложений и игр. [image06.png]
продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Всё это позволило Microsoft продать 10 млн копий за 2 года. Да, OS/2 была функциональнее, но она была дороже, сложнее и менее доступной массовому пользователю. И Microsoft поняла: зачем делиться OS/2 с IBM, если можно развивать Windows и контролировать рынок. А еще поняла, что пользователям важнее удобство и доступность, а не техническое совершенство. Именно в этот момент Microsoft приняла решение покинуть проект OS/2 и начать разработку Windows NT, опираясь на опыт, полученный во время работы над OS/2. А IBM продолжила развивать OS/2 самостоятельно.
Разблокировано воспоминание: Когда мне было лет 6, я дружил с девчонкой. Она жила несколькими этажами ниже. Я довольно часто бегал к ней в гости. А у нее был старший брат, который увлекался компами - и я вот помню как он мне хвастался что поставил на комп OS/2. Он был явно очень собой доволен и счастлив, что у него это получилось. Я не знаю как я это помню до сих пор, но почему то это отпечаталось в моей памяти.
В 1992 выходит OS/2 2.0 уже без участия Microsoft. Полноценная 32-битная система для 386, поддержка кооперативной и вытесняющей многозадачности, виртуализация DOS, запуск Windows-программ внутри - всё это было в новой операционной системе.
OS/2 могла одновременно запускать несколько Windows 3.0 приложений в отдельных защищённых сессиях. И это было даже безопаснее и стабильнее, чем сам Windows.
IBM продвигала OS/2 как “лучше Windows”, но этой ОС нужно было больше ОЗУ, места на диске, и драйвера ставились труднее. К тому же не каждый пользователь справлялся с установкой.
Выход Windows 3.1 в 1992 добил ситуацию. Простая установка, игры, драйвера - всё шло “из коробки”. OS/2 же оставалась системой для гиков и корпоративных клиентов.
В мае 1993 года IBM выпускает OS/2 2.1 и к концу 1993 года IBM занимает всего лишь менее четырех процентов рынка настольных компьютеров. Но начинает прокладывть себе путь как на рынок серверов и встраиваемых систем.
В 1994 IBM выпускает OS/2 Warp 3.0 и она стала самой популярной версией OS/2. Она предлагала поддержку мультимедиа, интернет-приложений и имела улучшенный интерфейс. Warp продавалась в коробках, рекламировалась в журналах и по ТВ.
IBM даже подписала контракт с DC Comics - выпускали комиксы о WarpMan, борющемся с “злыми синими окнами”. Но несмотря на юмор и креатив, успеха не вышло.
В 1995 выходит Windows 95. Поддержка Win32, современный GUI, огромная база разработчиков и массовая реклама от Microsoft сделали своё дело - окончательно добили OS/2 на рынке настольных ПК.
К концу 1996 года OS/2 завоевала почти тринадцать процентов рынка серверов и чуть более трех процентов рынка настольных ПК. Серверные версии OS/2 были технически превосходны и имели хорошую ценность, но NT быстро обгоняла OS/2, а Linux также начал отвоевывать часть рынка серверов.
В 2001 IBM выпустила последнюю версию - OS/2 Warp 4.52. После этого проект закрыли, но лицензии передали сторонним компаниям. Так появились eComStation и ArcaOS на базе OS/2.
ArcaOS - современное ответвление OS/2. Работает на новых процессорах, поддерживает USB 3.0, Wi-Fi, современные дисплеи и т.д. Система всё ещё используется в некоторых банках.
OS/2 была технически передовой системой, превосходящей Windows по многим параметрам, но проиграла из-за более высокой стоимости оборудования, сложности использования, неудачной маркетинговой стратегии. Но ключевым фактором стал разрыв отношений с Microsoft, которые вовремя поняли что пользователи не хотят настраивать систему, они хотят включить и чтобы сразу работало. Можем ли мы упрекнуть Microsoft в неэтичности по отношению к IBM вопрос открытый - решайте сами…
https://habr.com/ru/articles/906698/
#facts
Разблокировано воспоминание: Когда мне было лет 6, я дружил с девчонкой. Она жила несколькими этажами ниже. Я довольно часто бегал к ней в гости. А у нее был старший брат, который увлекался компами - и я вот помню как он мне хвастался что поставил на комп OS/2. Он был явно очень собой доволен и счастлив, что у него это получилось. Я не знаю как я это помню до сих пор, но почему то это отпечаталось в моей памяти.
В 1992 выходит OS/2 2.0 уже без участия Microsoft. Полноценная 32-битная система для 386, поддержка кооперативной и вытесняющей многозадачности, виртуализация DOS, запуск Windows-программ внутри - всё это было в новой операционной системе.
OS/2 могла одновременно запускать несколько Windows 3.0 приложений в отдельных защищённых сессиях. И это было даже безопаснее и стабильнее, чем сам Windows.
IBM продвигала OS/2 как “лучше Windows”, но этой ОС нужно было больше ОЗУ, места на диске, и драйвера ставились труднее. К тому же не каждый пользователь справлялся с установкой.
Выход Windows 3.1 в 1992 добил ситуацию. Простая установка, игры, драйвера - всё шло “из коробки”. OS/2 же оставалась системой для гиков и корпоративных клиентов.
В мае 1993 года IBM выпускает OS/2 2.1 и к концу 1993 года IBM занимает всего лишь менее четырех процентов рынка настольных компьютеров. Но начинает прокладывть себе путь как на рынок серверов и встраиваемых систем.
В 1994 IBM выпускает OS/2 Warp 3.0 и она стала самой популярной версией OS/2. Она предлагала поддержку мультимедиа, интернет-приложений и имела улучшенный интерфейс. Warp продавалась в коробках, рекламировалась в журналах и по ТВ.
IBM даже подписала контракт с DC Comics - выпускали комиксы о WarpMan, борющемся с “злыми синими окнами”. Но несмотря на юмор и креатив, успеха не вышло.
В 1995 выходит Windows 95. Поддержка Win32, современный GUI, огромная база разработчиков и массовая реклама от Microsoft сделали своё дело - окончательно добили OS/2 на рынке настольных ПК.
К концу 1996 года OS/2 завоевала почти тринадцать процентов рынка серверов и чуть более трех процентов рынка настольных ПК. Серверные версии OS/2 были технически превосходны и имели хорошую ценность, но NT быстро обгоняла OS/2, а Linux также начал отвоевывать часть рынка серверов.
В 2001 IBM выпустила последнюю версию - OS/2 Warp 4.52. После этого проект закрыли, но лицензии передали сторонним компаниям. Так появились eComStation и ArcaOS на базе OS/2.
ArcaOS - современное ответвление OS/2. Работает на новых процессорах, поддерживает USB 3.0, Wi-Fi, современные дисплеи и т.д. Система всё ещё используется в некоторых банках.
OS/2 была технически передовой системой, превосходящей Windows по многим параметрам, но проиграла из-за более высокой стоимости оборудования, сложности использования, неудачной маркетинговой стратегии. Но ключевым фактором стал разрыв отношений с Microsoft, которые вовремя поняли что пользователи не хотят настраивать систему, они хотят включить и чтобы сразу работало. Можем ли мы упрекнуть Microsoft в неэтичности по отношению к IBM вопрос открытый - решайте сами…
https://habr.com/ru/articles/906698/
#facts
👏6🔥3👍1
Сегодня поговорим как разогнать скорость передачи по сети на максимум всего за пару команд. В качестве примера представим, что у нас распределенная инфраструктура, которая живет в разных регионах. Также у нас есть какой то VPN между ЦОД-ами, который решает проблему связности ресурсов и безопасности. И есть требование: каждый час надо скачивать бекап на 50GB и разворачивать в другом регионе.
И вот вы настроили свой cronjob, запустили его и пошли пить чай и брать следующую таску в работу. Через какое то время обнаруживаете что скорость во время скачивания бекапа серьезно проседает, ну и плюс периодически могут теряться пакеты, а RTT вообще 30ms. И вот бекап уже даже за пару часов не может скачаться.
Это классическая история для алгоритма управления перегрузкой (Congestion Control Algorithms) CUBIC. Эти алгоритмы встроены в ядро операционных систем и работают автоматически, без вашего участия.
Но не все так плохо - Google начал придумывать более оптимальный алгоритм еще в 2016 и назвал его BBR (Bottleneck Bandwidth and Round-trip time). Алгоритм BBR проходит через несколько фаз, но для простоты можно выделить его основную логику:
1. Разведка: BBR периодически ненадолго увеличивает скорость отправки данных, чтобы проверить, не выросла ли пропускная способность канала (вдруг «трубу» расширили?).
2. Дренаж: После разведки он наоборот, немного снижает скорость, чтобы «осушить» возможные очереди из пакетов, которые могли скопиться в буферах маршрутизаторов, уменьшая задержку.
3. Стабильная работа: Основное время BBR работает на рассчитанной оптимальной скорости, которая обеспечивает максимальную пропускную способность при минимальной задержке.
Ключевое отличие в том, что CUBIC реагирует на потери, а BBR реагирует на изменения в сети (сравнение CUBIC и BBR на реальных устройствах от компании ESNet https://internet2.edu/wp-content/uploads/2022/12/techex22-AdvancedNetworking-ExploringtheBBRv2CongestionControlAlgorithm-Tierney.pdf)
BBR вы можете включить на свежих ядрах как Linux так и Windows:
# linux
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
# windows
NetTCPSetting | Select SettingName, CongestionProvider
netsh int tcp set supplemental template=Internet congestionprovider=BBR2
netsh int tcp set supplemental template=InternetCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Datacenter congestionprovider=BBR2
netsh int tcp set supplemental template=DatacenterCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Compat congestionprovider=BBR2
Где можно попробовать включать: между облаками/ЦОДами (NAT и VPN-шлюзы), а также конечные сервера где требуется просасывать большие объемы трафика.
На моей практике включение BBR на конечных серверах и VPN-инстансах дало буст по сетке x6. Но вы должны иметь ввиду, что BBR может быть довольно агрессивен по отношению к соседям использующим CUBIC - поэтому после включения стоит понаблюдать за ситуацией. А сравнить эффективность вы можете через
iperf3 -c YOUR_IP -t 60 -P 16.#linux #networking
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16
В практике иногда встречаются кейсы когда нужно проверить как себя ведет приложение при сетевых проблемах. На помощь спешит tc netem (аббревиатура от Network Emulator) — инструмент Linux для эмуляции сетевых проблем.
netem — это qdisc (queueing discipline) в Linux — часть подсистемы управления трафиком (tc из iproute2). Его задача симулировать реальные сетевые проблемы: задержки, потери пакетов, дубликации, неправильный порядок, ограничение пропускной способности и т.д.
Когда и зачем использовать
Тестирование протоколов — например, TCP или VoIP, если хочешь увидеть, как они ведут себя при потере и/или задержке.
Разработка приложений, чтобы убедиться, что сценарии “плохой сети” обрабатываются корректно.
Реалистичная нагрузка — эмуляция загруженных сетей или мобильных сетей, где часто бывают потери, задержки, “хвосты” задержек.
Добавить фиксированную задержку
sudo tc qdisc add dev eth0 root netem delay 100ms
Добавить задержку + джиттер с корреляцией
Эта команда, которая эмулирует не просто "плохую" сеть, а нестабильную сеть с "памятью". Гораздо ближе к реальным условиям (например, к мобильным сетям 3G/4G/5G или перегруженным каналам).
sudo tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
delay 100ms средняя задержка, вокруг которой будут "колебаться" ваши пакеты. 10ms — джиттер (величина, на которую задержка может случайным образом отклоняться). В данном случае задержка каждого пакета будет выбираться случайным образом из диапазона от 90ms до 110ms (100ms ± 10ms). Без корреляции это были бы просто случайные, независимые друг от друга значения.
Корреляция 25% это параметр, который определяет, насколько задержка текущего пакета зависит от задержки предыдущего пакета. Без корреляции (0%) джиттер дает абсолютно случайные и независимые скачки задержки. Это не очень реалистично для многих реальных сетей. С корреляцией 25%: если предыдущий пакет имел задержку (например, 110 мс), то высока вероятность, что и следующий пакет тоже будет иметь задержку выше среднего. Таким образом мы получаем некий эффект "памяти" сети. Это дает более реальное поведение сетей для тестирования.
Добавить "нормальное" распределение задержек
Большинство пакетов получают задержку, близкую к среднему значению. Крайние значения (сильные отклонения) маловероятны, но возможны. Данный тип использует Гауссово распределение. Существуют и другие:`uniform`,
pareto, paretonormal.
sudo tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
Потеря пакетов
sudo tc qdisc change dev eth0 root netem loss 20%
Дубликация пакетов
Эта команда инструктирует ядро Linux изменить текущие сетевые правила на сетевом интерфейсе eth0 так, чтобы он случайным образом дублировал 1% всех исходящих сетевых пакетов. Допустим, что ваше приложение отправляет 1000 пакетов. При включенном правиле duplicate 1%: ~990 пакетов дойдут до получателя в нормальном, единственном экземпляре. ~10 пакетов будут дублированы. Получатель получит их в двух одинаковых копиях, одна сразу за другой. Полезно при тестирование устойчивости протоколов и приложений. Например, как поведет себя кодек или игровой движок.
sudo tc qdisc change dev eth0 root netem duplicate 1%
Ограничение пропускной способности + учёт overhead
Использование overhead позволяет ограничить скорость именно на уровне полезных данных, которую увидит приложение, что критически важно для корректного тестирования пропускной способности. Для грубого ограничения "лишь бы было медленнее" можно использовать просто rate 5mbit, но для точных реалистичной эмуляции канала связи учет overhead обязателен.
sudo tc qdisc change dev eth0 root netem rate 5mbit 20 1500 5
rate 5mbit скорость полезной нагрузки
20 размер заголовков канального уровня (L2)
1500 размер MTU
5 размер в байтах сетевого и транспортного уровня (L3+L4)
Почистить за собой
sudo tc qdisc delete dev eth0 root netem
#linux #networking
Please open Telegram to view this post
VIEW IN TELEGRAM
👏8👍7🔥4
Все мы любим htop - цветастый, кликабельный, удобный топчик. Но не смотря на то, что в большинстве случаев хватает варианта из коробки, в нем большие возможности для кастомизации.
Я не хочу долго расписывать как и что настраивать, а просто дам вам однострочник который сделает всю магию. Он по сути он просто бекапит текущий конфиг (если он вообще был) и забирает из https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f новый.
mkdir -p ~/.config/htop && [ -f ~/.config/htop/htoprc ] && mv ~/.config/htop/htoprc ~/.config/htop/htoprc.bak.$(date +%Y%m%d%H%M%S); curl -fsSL "https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f/raw" -o ~/.config/htop/htoprc
После этого запускаем htop и наслаждаемся.
#tools
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12 2❤🔥1 1
Этот пет-проект я начинал делать с единственной целью “понять а как это работает на самом деле”, но он уже оброс кое-какими mcp-тулзами и, кажется, пришло время им поделиться. Если у вас есть TeamCity и количество билд конфигураций в нем такое, что чёрт ногу сломит - то скорее всего данный MCP Server вам будет полезен. В данный момент в нем реализованы следующие тулзы:
### Поиск и анализ
1. `search_builds` — Поиск билдов по статусу, ветке, дате, тегам, пользователю
2. `search_build_configurations` — Поиск конфигураций по параметрам, шагам, VCS
3. `fetch_build_log` — Получение логов билда для диагностики
### Управление билдами
1. `trigger_build` — Запуск нового билда с параметрами и указанием ветки
2. `cancel_build` — Отмена запущенного или ожидающего билда
3. `pin_build` — Закрепление/открепление билда для предотвращения автоудаления
### Управление метаданными и артефактами
1. `set_build_tag` — Добавление/удаление тегов к билдам
2. `download_artifact` — Скачивание артефактов из билда
Примеры использования
"Покажи все FAILURE билды за сегодня"
"Найди самые медленные билды в проекте shitcode"
"Почему свалилась сборка #2321 и как это исправить"
"Запусти билд MyProject_Deploy на ветке main"
"Закрепи билд #1234 с тегом v.1.0.7"
Настроить очень просто - создаем токен в Teamcity (я рекомендую придерживаться принципа PoLP) и задаем конфигурацию MCP.
# Пример подключения в Cursor
{
"mcpServers": {
"teamcity": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"TC_URL",
"-e",
"TC_TOKEN",
"itcaat/teamcity-mcp:v1.0.7",
"--transport",
"stdio"
],
"env": {
"TC_URL": "https://teamcity.example.com",
"TC_TOKEN": "YOUR_TOKEN_HERE"
}
}
}
}
В дальнейшем в нем появятся тулы для создания билд конфигураций. А сами исходники доступны тут https://github.com/itcaat/teamcity-mcp (буду очень благодарен за ⭐). На этом у меня всё - всем пока и приятного пользования.
#cicd #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5 1 1
Подъезжают первые комплектухи. Старший сын попросил такой же "комп для учебы" как и у младшего. Приходится раскошеливаться, чтобы было справедливо.
Потом покажу что получилось 🤌
#fun
Потом покажу что получилось 🤌
#fun
Сегодня мы с вами на практике разберем что такое динамические матрицы в github actions.
Я подготовил монорепозиторий с несколькими микросервисами url-shortener-demo с очень коротким флоу: фичабранч(через PR) → main. Как понятно из названия это проект позволяющий генерировать короткие ссылки. А для упрощения локального запуска подготовлен docker-compose.yml, состоящий из сервисов:
1. api-gateway (Go) - API Gateway, единая точка входа
2. shortener-service (Go + Redis) - Создание коротких URL
3. redirect-service (Go + Redis + Kafka) - Перенаправление + события перехода для аналитики
4. analytics-service (Go + MongoDB + Kafka) - Аналитика
5. frontend (HTML + Nginx) - Веб-интерфейс
Дальше надо прикрутить сборку и пуш образов наших микросервисов. В структуре репа в корне лежат одноименные сервисы + каталог pkg, в котором будут храниться общие либы. Каждый сервис внутри имеет свой Dockerfile - это важный признак того, что это конечный сервис который можно собрать.
Теперь про магию - на самом деле вы, наверняка, видели множество примеров со статичными матрицами сборки (например, когда сборка приложения делается на нескольких OS). Но что если пойти дальше и самому сгенерировать матрицу в зависимости от того что поменялось? К счастью github actions позволяет нам это сделать.
При создании PR мы автоматически можем определить какой сервис поменялся, собрать его и выложить. А в случае, если поменялось что-то в pkg - собрать все сервисы.
# .github/workflows/build-pr.yml - часть 1
name: Build Pull Request
jobs:
changed-services:
name: Detect changed services
runs-on: ubuntu-latest
outputs:
matrix: ${{ steps.set-matrix.outputs.matrix }}
any_changed: ${{ steps.changed-files.outputs.any_changed }}
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Get changed services
id: changed-files
uses: tj-actions/changed-files@v45
with:
dir_names: true
dir_names_max_depth: 1
json: true
files: |
**/*
files_ignore: |
**/*.md
.github/**
scripts/**
*.md
- name: List all changed files
run: |
echo "Changed files: ${{ steps.changed-files.outputs.all_changed_files }}"
- name: Set matrix
id: set-matrix
run: |
# Находим все директории с Dockerfile
ALL_SERVICES=$(find . -maxdepth 2 -name "Dockerfile" -type f | sed 's|^\./||' | sed 's|/Dockerfile$||' | jq -R -s 'split("\n") | map(select(length > 0))' | jq -c .)
echo "All services with Dockerfile: $ALL_SERVICES"
# Получаем измененные файлы и убираем экранирование
CHANGED_DIRS_RAW='${{ steps.changed-files.outputs.all_changed_files }}'
CHANGED_DIRS=$(echo "$CHANGED_DIRS_RAW" | sed 's/\\"/"/g')
echo "Changed directories: $CHANGED_DIRS"
# Если изменился pkg/, пересобираем все Go сервисы (с go.mod)
if echo "$CHANGED_DIRS" | jq -e 'index("pkg")' > /dev/null 2>&1; then
SERVICES=$(find . -maxdepth 2 -name "go.mod" -type f | sed 's|^\./||' | sed 's|/go.mod$||' | jq -R -s 'split("\n") | map(select(length > 0))' | jq -c .)
echo "pkg/ changed, rebuilding all Go services: $SERVICES"
else
# Фильтруем: оставляем только измененные директории с Dockerfile
SERVICES=$(jq -nc --argjson all "$ALL_SERVICES" --argjson changed "$CHANGED_DIRS" \
'$changed | map(select(. as $dir | $all | index($dir)))' | jq -c .)
echo "Changed services: $SERVICES"
fi
# Если нет сервисов для сборки, создаем пустой массив
if [ "$SERVICES" = "[]" ] || [ -z "$SERVICES" ]; then
echo "No services to build"
SERVICES="[]"
fi
echo "matrix={\"service\":$SERVICES}" >> "$GITHUB_OUTPUT"
Продолжение далее…
#github_actions
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4