Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351
Post #4080
1.41K
🔄 Как перестать тратить ресурсы CI/CD впустую
Каждый пуш в монорепозитории запускает полный пайплайн — даже если вы поправили всего один файл. Время уходит на ненужные сборки, ресурсы сгорают, разработчики ждут. Решение простое и элегантное: селективные пайплайны, которые запускают только те задачи, которых касались изменения.
В GitHub Actions удобно использовать стандартные триггеры или
Пример:
В GitLab этот механизм встроен в rules:changes. Можно настроить как отдельные jobs, так и дочерние пайплайны для разных модулей. Например, API живёт своей жизнью, фронтенд — своей, а объединяет их только Merge Request.
Пример:
Не забывайте добавлять в фильтры и глобальные файлы — вроде package-lock.json или .gitlab-ci.yml. Они влияют на весь проект, и пропускать их опасно.
🐸Библиотека devops'a
#арсенал_инженера
Каждый пуш в монорепозитории запускает полный пайплайн — даже если вы поправили всего один файл. Время уходит на ненужные сборки, ресурсы сгорают, разработчики ждут. Решение простое и элегантное: селективные пайплайны, которые запускают только те задачи, которых касались изменения.
В GitHub Actions удобно использовать стандартные триггеры или
dorny/paths-filter: он проверяет diff и включает лишь нужные джобы. Меняли api/ — запускается сборка API. Вносили правки в web/ — прогоняются тесты фронтенда. Тронули infra/** — стартует деплой инфраструктуры. Всё остальное CI просто пропускает.Пример:
# .github/workflows/ci.yaml
name: CI
on:
pull_request:
paths:
- "api/**"
- "web/**"
- "infra/**"
push:
branches: [ main ]
paths:
- "api/**"
- "web/**"
- "infra/**"
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: echo "Собираем, потому что изменились файлы из paths"
В GitLab этот механизм встроен в rules:changes. Можно настроить как отдельные jobs, так и дочерние пайплайны для разных модулей. Например, API живёт своей жизнью, фронтенд — своей, а объединяет их только Merge Request.
Пример:
stages: [build, test, deploy]
build_api:
stage: build
rules:
- changes:
- api/**
- package.json # глобальный файл, влияющий на сборку API
when: on_success
- when: never
script:
- echo "Build API"; # ваши шаги
test_web:
stage: test
rules:
- changes:
- web/**
- package.json
when: on_success
- when: never
script:
- echo "Test Web"
deploy_infra:
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"
changes:
- infra/**
- .gitlab-ci.yml
when: on_success
- when: never
script:
- echo "Deploy Infra"
Не забывайте добавлять в фильтры и глобальные файлы — вроде package-lock.json или .gitlab-ci.yml. Они влияют на весь проект, и пропускать их опасно.
🐸Библиотека devops'a
#арсенал_инженера
- ❤ 6
- 👍 4
