Разбираем, как правильно очищать pipelines, jobs, artifacts и историю коммитов в актуальных версиях GitLab (PostgreSQL 16, partitioned CI schema). Без устаревших DELETE FROM ci_builds; и без поломки инстанса.
Кратко: не лезем слепо в SQL → используем Rails console или TRUNCATE CASCADE → учитываем partitioned tables → после очистки делаем vacuum.
Актуальные основные таблицы:
ci_pipelinesci_running_buildsci_pending_buildsci_pipeline_artifactsci_pipeline_metadataci_build_trace_chunksМногие из них — partitioned. Это значит, что обычный DELETE не всегда корректен.
Самый правильный способ — через встроенные модели GitLab.
sudo gitlab-rails console
project = Project.find_by_full_path('group/project')
project.ci_pipelines.destroy_all
Ci::JobArtifact.destroy_all
Ci::Build.destroy_all
Это безопасно, потому что GitLab сам корректно обработает связи и каскады.
Подключаемся:
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 не даст удалить записи.
Если таблицы partitioned — лучше использовать:
TRUNCATE ci_pipelines CASCADE;
Проверить partition:
SELECT relname
FROM pg_class
WHERE relkind = 'p';
TRUNCATE быстрее и безопаснее для полной очистки CI.
После очистки:
VACUUM FULL ANALYZE;
Самый продовый способ:
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 исчезнут.
GitLab последних версий сильно усложнил CI-схему. Старые методы 2018–2021 годов больше не актуальны.
Если цель — уменьшить размер базы, сначала используйте встроенные cleanup-механизмы, а не прямой SQL.
“Зачем поднимать свои CI-сервера, если можно использовать облако Serverless CI решает инфраструктурные проблемы, а Multi-cloud — даёт гибкость и отказоустойчивость.” ⚡
Multi-Cloud — это стратегия, при которой ты используешь несколько облачных провайдеров одновременно (например, AWS + GCP + Yandex.Cloud), чтобы:
CI/CD в multi-cloud окружении позволяет строить гибкие и распределённые pipeline’ы, которые живут не в одном датацентре, а где нужно.
Serverless CI — это когда ты не управляешь собственной CI-инфраструктурой (VM, k8s), а используешь облачные раннеры или полностью управляемые пайплайны.
| Что ты не делаешь | Что делает облако |
|---|---|
| Разворачиваешь GitLab Runner или Jenkins | ✅ Автоматически выделяет раннеры |
| Следишь за масштабированием | ✅ Автоскейл по нагрузке |
| Чинишь падающие агенты | ✅ Облако само менеджит окружение |
| Платишь за 24/7 сервера | ✅ Платишь только за минуты выполнения |
Пайплайны становятся быстрее, масштабируются по запросу и не требуют поддержки
GitHub Actions — один из самых популярных serverless CI-сервисов. Он позволяет запускать пайплайны прямо из репозитория, используя готовые раннеры GitHub.
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’ы.
GitLab предлагает облачные shared runners, которые можно использовать без установки своих. Для Multi-cloud сценариев — это :
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 — это 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 можно запустить:
Serverless CI не отменяет правил безопасности. Нужно внимательно работать с секретами и доступами:
Это особенно важно в multi-cloud окружении, где можно случайно открыть ключ сразу для всех регионов
| Паттерн | Описание | Пример |
|---|---|---|
| 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 + Serverless CI — это современный способ строить распределённые и надёжные пайплайны. Ты получаешь скорость, отказоустойчивость и безопасность, не управляя лишними VM и k8s кластерами.
CI становится “эластичным” и живёт там, где нужно твоим приложениям — не наоборот.