Разбираем, как правильно очищать pipelines, jobs, artifacts и историю коммитов в актуальных версиях GitLab (PostgreSQL 16, partitioned CI schema). Без устаревших DELETE FROM ci_builds; и без поломки инстанса.

Кратко: не лезем слепо в SQL → используем Rails console или TRUNCATE CASCADE → учитываем partitioned tables → после очистки делаем vacuum.



Как теперь устроен CI в GitLab

Актуальные основные таблицы:

  • ci_pipelines
  • ci_running_builds
  • ci_pending_builds
  • ci_pipeline_artifacts
  • ci_pipeline_metadata
  • ci_build_trace_chunks

Многие из них — partitioned. Это значит, что обычный DELETE не всегда корректен.


Безопасная очистка через Rails Console (рекомендуется)

Самый правильный способ — через встроенные модели GitLab.

sudo gitlab-rails console

Удалить пайплайны конкретного проекта


project = Project.find_by_full_path('group/project')
project.ci_pipelines.destroy_all

Удалить все job artifacts


Ci::JobArtifact.destroy_all

Удалить все CI build записи


Ci::Build.destroy_all

Это безопасно, потому что GitLab сам корректно обработает связи и каскады.


Очистка через psql (если очень нужно)

Подключаемся:

sudo gitlab-psql

Сначала смотрим актуальные таблицы:

\dt ci_*

Если нужно очистить вручную:


DELETE FROM ci_pipeline_artifacts;
DELETE FROM ci_pipeline_metadata;
DELETE FROM ci_pipeline_messages;
DELETE FROM ci_build_trace_chunks;
DELETE FROM ci_running_builds;
DELETE FROM ci_pending_builds;
DELETE FROM ci_pipelines;

Порядок важен. Иначе FK не даст удалить записи.


TRUNCATE для partitioned таблиц

Если таблицы partitioned — лучше использовать:

TRUNCATE ci_pipelines CASCADE;

Проверить partition:


SELECT relname 
FROM pg_class 
WHERE relkind = 'p';

TRUNCATE быстрее и безопаснее для полной очистки CI.

После очистки:

VACUUM FULL ANALYZE;

Очистка artifacts и CI через rake

Самый продовый способ:


gitlab-rake gitlab:artifacts:cleanup
gitlab-rake gitlab:ci:cleanup

Для удаления всех pipelines:

gitlab-rake gitlab:ci:delete_all_pipelines

Этот способ не ломает внутренние зависимости.


Очистка коммитов (полный ресет истории)

Если нужно начать историю проекта "с нуля":


git checkout --orphan clean-branch
git add .
git commit -m "Initial clean commit"
git branch -D main
git branch -m main
git push -f origin main

Важно: это перепишет историю. Все старые commit SHA исчезнут.


Рекомендации и подводные камни

  • Не удаляйте CI таблицы по одной без понимания зависимостей.
  • Partitioned tables требуют TRUNCATE.
  • После массовой очистки всегда делайте VACUUM.
  • В проде лучше использовать Rails console или rake.
  • Force-push коммитов ломает fork'и и MR.

GitLab последних версий сильно усложнил CI-схему. Старые методы 2018–2021 годов больше не актуальны.

Если цель — уменьшить размер базы, сначала используйте встроенные cleanup-механизмы, а не прямой SQL.

Multi-Cloud и Serverless CI: GitHub Actions, GitLab Cloud Runners и Tekton

“Зачем поднимать свои CI-сервера, если можно использовать облако Serverless CI решает инфраструктурные проблемы, а Multi-cloud — даёт гибкость и отказоустойчивость.” ⚡

Что такое Multi-Cloud

Multi-Cloud — это стратегия, при которой ты используешь несколько облачных провайдеров одновременно (например, AWS + GCP + Yandex.Cloud), чтобы:

  • повысить отказоустойчивость
  • избежать vendor lock-in
  • оптимизировать стоимость
  • запускать пайплайны ближе к конкретным окружениям или регионам

CI/CD в multi-cloud окружении позволяет строить гибкие и распределённые pipeline’ы, которые живут не в одном датацентре, а где нужно.

Serverless CI: концепт

Serverless CI — это когда ты не управляешь собственной CI-инфраструктурой (VM, k8s), а используешь облачные раннеры или полностью управляемые пайплайны.

Что ты не делаешь Что делает облако
Разворачиваешь GitLab Runner или Jenkins ✅ Автоматически выделяет раннеры
Следишь за масштабированием ✅ Автоскейл по нагрузке
Чинишь падающие агенты ✅ Облако само менеджит окружение
Платишь за 24/7 сервера ✅ Платишь только за минуты выполнения

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

GitHub Actions — CI/CD без серверов

GitHub Actions — один из самых популярных serverless CI-сервисов. Он позволяет запускать пайплайны прямо из репозитория, используя готовые раннеры GitHub.

Пример деплоя в Multi-cloud

name: Multi-cloud Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy-aws:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to AWS
        run: ./deploy/aws.sh

  deploy-gcp:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to GCP
        run: ./deploy/gcp.sh

Один репозиторий → несколько клаудов → параллельные job’ы.

Фишки:

  • Reusable workflows
  • Secrets и environments с granular access
  • Matrix builds для мультиплатформы
  • Self-hosted runners для edge-случаев

GitLab Cloud Runners

GitLab предлагает облачные shared runners, которые можно использовать без установки своих. Для Multi-cloud сценариев — это :

  • Запуск job’ов в разных регионах параллельно
  • Подключение внешних Kubernetes кластеров
  • Интеграция с облачными функциями или контейнерами

Пример serverless пайплайна

stages:
  - test
  - deploy

test:
  stage: test
  script:
    - pytest

deploy_aws:
  stage: deploy
  script:
    - ./deploy/aws.sh
  tags: [cloud]

deploy_gcp:
  stage: deploy
  script:
    - ./deploy/gcp.sh
  tags: [cloud]

Можно комбинировать shared runners и custom k8s runners для edge/secure зон.

Tekton Pipelines — Cloud Native CI

Tekton — это Kubernetes-native CI/CD платформа, которая идеально вписывается в Multi-cloud архитектуру. Ты описываешь pipeline как Kubernetes ресурсы, а Tekton сам их исполняет.

Пример таски

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: deploy-aws
spec:
  steps:
    - name: deploy
      image: alpine
      script: |
        #!/bin/sh
        ./deploy/aws.sh

Tekton можно запустить:

  • в каждом облаке (AWS, GCP, Azure)
  • централизованно в одном Kubernetes
  • в гибридном режиме с GitOps (ArgoCD + Tekton)

Безопасность и секреты

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

  • Используй OIDC (GitHub Actions → AWS/GCP) вместо долгоживущих ключей
  • Храни секреты в CI Secrets store, а не в репозитории
  • Разграничивай доступ по окружениям (prod/stage/dev)
  • Используй short-lived токены и policy-based access

Это особенно важно в multi-cloud окружении, где можно случайно открыть ключ сразу для всех регионов

Multi-cloud паттерны CI

Паттерн Описание Пример
Parallel Deploy Одновременный деплой в несколько облаков GitHub Actions с 2 job’ами
Geo Routing Pipeline выбирает облако по региону Tekton Task + custom params
Failover Если облако A упало — задеплой в B GitLab CI + rules / retry
Hybrid Облако для CI, On-Prem для sensitive GitLab Cloud Runner + self-hosted

Преимущества подхода

  • Быстрые пайплайны без серверов
  • Гибкость Multi-cloud без vendor lock-in
  • Меньше инфраструктуры → меньше DevOps overhead
  • Безопасность через managed identity и secrets
  • Легкий масштаб без боли с Kubernetes кластерами CI

Заключение

Multi-cloud + Serverless CI — это современный способ строить распределённые и надёжные пайплайны. Ты получаешь скорость, отказоустойчивость и безопасность, не управляя лишними VM и k8s кластерами.

CI становится “эластичным” и живёт там, где нужно твоим приложениям — не наоборот.

Popular Posts

Advertisement

Headlines