Знакомимся с интерфейсом GitLab

Перед первой лабораторной посмотрим на интерфейс и куда ты попадаешь после открытия GitLab и где искать основные разделы. Если ты раньше не работал с GitLab, не пытайся сразу запоминать все пункты меню. В этом курсе тебе понадобится небольшой набор действий, и мы будем возвращаться к ним постепенно.

В этом видео быстро познакомимся с основными разделами GitLab, которые понадобятся в лабораторных.

GitLab умеет очень много: хранить репозитории, вести задачи, делать code review, запускать CI/CD, хранить Docker images, показывать окружения, работать с секретами и правами доступа. Поэтому в интерфейсе много разделов. Сейчас наша цель: pipeline, job log, variables, registry и environments. Остальное можно спокойно игнорировать до момента, когда оно понадобится.

В лабораторной у тебя всегда есть две части:

• веб-интерфейс GitLab в браузере;
• терминал учебной VM, где уже склонирован репозиторий.

Кнопка Web Preview находится справа вверху, слева от кнопки Остановить. Она открывает GitLab в браузере. Если GitLab показывает страницу входа, логин и пароль нужно взять в терминале:

cat /root/gitlab-ci.env

В файле будут строки:

GITLAB_USERNAME=...
GITLAB_PASSWORD=...
GITLAB_REPO=...
GITLAB_REGISTRY=...

Для входа в браузере используй GITLAB_USERNAME и GITLAB_PASSWORD. Пароль нужен именно для веб-интерфейса. Для git push в терминале уже настроен token в remote URL, поэтому вручную вставлять пароль в Git-команды не нужно.

Где находится проект

После входа тебе нужно открыть свой личный проект ci-deploy-lab. В лабораторной имя пользователя GitLab обычно выглядит как vm-..., потому что аккаунт создаётся автоматически для конкретной учебной VM.

Делай так:

1. В левом меню открой Projects, если GitLab не открыл этот экран сам.
2. Вверху списка проектов нажми вкладку Personal. Она показывает проекты твоего пользователя.
3. В списке ниже найди строку vm-... / ci-deploy-lab.
4. Нажми именно на название ci-deploy-lab.

Строка может выглядеть примерно так: vm-d9b... / ci-deploy-lab.

Первая часть vm-d9b... - это твой временный GitLab-пользователь. Вторая часть ci-deploy-lab - сам проект курса.

Короткий путь:

Projects -> Personal -> ci-deploy-lab

Когда проект откроется, вверху страницы и в левом меню будет видно ci-deploy-lab. Это главный признак, что ты находишься не просто в GitLab, а именно внутри нужного проекта лабораторной.

Это важно: в каждой лабораторной создаётся отдельный пользователь GitLab и отдельный приватный проект. Проект не общий. Он привязан к твоей учебной VM и удаляется вместе с временной средой. Внутри проекта будут файлы репозитория, pipeline, jobs, variables, registry и environments.

Репозиторий в браузере и на VM

Один и тот же репозиторий доступен в двух местах.

В GitLab UI ты видишь его как проект:

Projects -> Personal -> ci-deploy-lab

На учебной VM этот проект уже склонирован в папку:

cd /root/gitlab-ci-lab

Именно эту папку открывай в VSCode. В ней ты будешь редактировать .gitlab-ci.yml, добавлять файлы, делать commit и push:

cd /root/gitlab-ci-lab
git status
git add .gitlab-ci.yml
git commit -m "Update pipeline"
git push origin main

Связь простая:

Файлы в /root/gitlab-ci-lab -> git push -> проект ci-deploy-lab в GitLab

Если ты изменил файл в терминале, GitLab не увидит изменение до git commit и git push. Если ты открыл файл в браузере, это только просмотр текущего состояния репозитория на сервере.

Работать можно двумя способами:

• редактировать файлы и выполнять git add, git commit, git push прямо в терминале;
• редактировать файлы и делать commit/push через интерфейс VSCode.

Если делаешь commit через VSCode, при первом commit редактор может спросить:

There are no staged changes to commit.

Would you like to stage all your changes and commit them directly?

Нажми Always. Это означает, что VSCode сам добавит изменённые файлы в commit, если ты не сделал git add вручную.

После нажатия Sync VSCode может показать ещё одно подтверждение:

This action will pull and push commits from and to "origin/main".

Нажми Ok, don't show again. Это обычное подтверждение синхронизации: VSCode проверит изменения на сервере и отправит твой commit в origin/main.

Где смотреть pipeline

Главный раздел курса: Build → Pipelines.

Pipeline - это один запуск CI/CD-конвейера. Обычно он появляется после git push. В списке pipeline ты смотришь:

• ветку или тег, например main или v0.1.0;
• статус: passed, failed, running, manual;
• время запуска;
• commit, из которого pipeline был создан.

Чтобы посмотреть подробности:

1. Открой Build -> Pipelines.
2. В списке найди верхнюю строку: обычно это последний запуск.
3. Нажми на эту строку pipeline или на его номер, например #104.
4. Откроется страница pipeline со списком jobs.

1. Нажми на имя нужного job, например hello-ci, build-image или deploy-compose.
2. Откроется страница job. В центре страницы будет большой текстовый log: это вывод команд из script.
3. Если job красный, пролистай log ближе к концу и найди первую понятную ошибку: command not found, yaml invalid, No such file, permission denied, docker build failed.

Log job - это главный источник диагностики. Если pipeline упал, сначала открой красный job: нажми на его имя в списке jobs, дождись страницы с log и посмотри, какая команда завершилась ошибкой.

На странице job почти всегда смотри три вещи:

1. Статус job: passed, failed, running или manual.
2. Log job: большой текстовый блок с выводом команд.
3. Список связанных jobs справа: по нему удобно перейти к соседней задаче pipeline.

Отдельный путь для списка jobs: Build → Jobs.

Этот раздел удобен, когда нужно быстро найти конкретный job без поиска его через pipeline. Там тоже можно нажать на имя job, и GitLab откроет ту же страницу с log.

Где редактировать .gitlab-ci.yml

В этом курсе основной способ - редактировать файл в VSCode внутри лабораторной VM. После запуска VM нажми кнопку VSCode в правой части панели лаборатории и дождись, пока откроется редактор.

Когда VSCode загрузится, открой папку gitlab-ci-lab в дереве файлов слева и редактируй .gitlab-ci.yml там. Если удобнее работать из терминала, можно открыть файл через Vim:

cd /root/gitlab-ci-lab
vim .gitlab-ci.yml

В GitLab также есть редактор Build → Pipeline editor.

Он полезен, чтобы посмотреть структуру .gitlab-ci.yml и проверить синтаксис. Но в лабораторных команды рассчитаны на работу из /root/gitlab-ci-lab, потому что так лучше видно полный цикл:

изменил файл -> commit -> push -> pipeline

Какие разделы понадобятся дальше

Не все разделы GitLab нужны сразу. Запомни базовую карту:

Раздел	Путь	Зачем нужен
Репозиторий	Projects -> Personal -> ci-deploy-lab	Смотреть файлы проекта
Pipeline	Build -> Pipelines	Смотреть запуски CI/CD
Jobs	Build -> Jobs	Смотреть отдельные job и их logs
Pipeline editor	Build -> Pipeline editor	Проверять .gitlab-ci.yml
Variables	Settings -> CI/CD -> Variables	Хранить настройки и секреты проекта
Container Registry	Deploy -> Container Registry	Смотреть Docker images проекта
Environments	Operate -> Environments	Смотреть окружения и историю deploy

В первых лабораторных тебе чаще всего нужны Personal, Build -> Pipelines и Build -> Jobs. Позже появятся variables, registry и environments: в соответствующих главах будут отдельные скриншоты этих разделов.

Что делать, если потерялся в интерфейсе

Вернись к этой последовательности:

1. Нажми Web Preview справа вверху, слева от Остановить.
2. Войди с GITLAB_USERNAME и GITLAB_PASSWORD из /root/gitlab-ci.env.
3. Открой Projects -> Personal -> ci-deploy-lab.
4. В терминале перейди в локальную копию:

cd /root/gitlab-ci-lab

1. После изменения файлов сделай:

git status
git add .
git commit -m "Update lab"
git push origin main

1. В GitLab открой:

Build -> Pipelines -> последний pipeline

Если pipeline красный, действуй так:

1. Нажми на последний pipeline.
2. На странице pipeline найди красный job.
3. Нажми на имя этого job.
4. Откроется log job.
5. Читай log ближе к концу: обычно GitLab показывает команду, которая упала, и сообщение ошибки.

Обычно ошибка прямо говорит, что случилось: YAML невалиден, команда не найдена, файл отсутствует, Docker image не собрался или переменная не задана.

Главное правило

GitLab UI показывает результат, а рабочая копия /root/gitlab-ci-lab на VM - место, где ты вносишь изменения. Удобнее всего делать это через VSCode, а команды git status, git add, git commit и git push выполнять в терминале.

/root/gitlab-ci-lab  ->  git push  ->  GitLab project  ->  pipeline  ->  job logs

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