Что начинается с точки в GitLab CI

Начинается с точки в GitLab CI

В контексте GitLab CI/CD символ точки (.) в начале имени файла или директории обычно указывает на скрытый файл или папку в Unix-подобных системах. Однако, если говорить конкретно о GitLab CI, есть несколько ключевых элементов, которые начинаются с точки, и они играют важную роль в настройке и работе пайплайнов.

1. .gitlab-ci.yml — основной файл конфигурации

Это главный и обязательный файл для работы GitLab CI/CD. Он определяет структуру, этапы и задачи пайплайна. Файл должен находиться в корне репозитория. Вот пример базовой структуры:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Сборка проекта..."
    - make build

test_job:
  stage: test
  script:
    - echo "Запуск тестов..."
    - make test

deploy_job:
  stage: deploy
  script:
    - echo "Деплой на сервер..."
  only:
    - main

• stages определяет последовательность этапов пайплайна.
• Каждый job (задача) привязан к этапу и содержит инструкции в script.
• Файл позволяет автоматизировать сборку, тестирование и развертывание приложений.

2. .gitlab/ директория — для расширенной конфигурации

Хотя сама директория начинается с точки, внутри неё могут находиться специфичные для GitLab файлы, например:

• .gitlab/ci/ включает дополнительные YAML-файлы для разбиения конфигурации (например, include для модульности).
• .gitlab/merge_request_templates/ для шаблонов merge request. Пример использования вложенного файла конфигурации в .gitlab-ci.yml:

include:
  - '.gitlab/ci/build-config.yml'
  - '.gitlab/ci/test-config.yml'

Это улучшает поддерживаемость и переиспользование кода в больших проектах.

3. Скрытые артефакты и кэши

В контексте выполнения jobs, точки могут появляться в путях для скрытых файлов, которые GitLab CI создаёт автоматически:

• Кэширование (cache) и артефакты (artifacts) часто хранятся во временных скрытых директориях (например, ./.cache/), чтобы ускорить последующие запуски пайплайнов. Пример настройки кэша:

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - .cache/
    - node_modules/

4. .env файлы и переменные окружения

Хотя не специфично для GitLab CI, файлы типа .env (например, .env.production) могут использоваться в пайплайнах для управления переменными окружения. Их можно загружать с помощью source в скриптах:

source .env.production

В GitLab CI переменные также можно задавать через настройки проекта в UI, что безопаснее для секретных данных.

5. Специальные директивы и шаблоны

В YAML-синтаксисе GitLab CI точка может использоваться в якорях и алиасах (например, &anchor и *alias) для повторного использования кода, но это не связано с началом имени файла. Однако, в контексте шаблонов, точка служит разделителем в названиях jobs для организации (например, build:linux).

Почему это важно?

• Стандартизация: Файлы, начинающиеся с точки, следуют соглашениям Unix, что упрощает работу в CI/CD-среде, основанной на Linux-контейнерах.
• Автоматизация: GitLab CI автоматически обнаруживает .gitlab-ci.yml при пуше в репозиторий, запуская пайплайн без ручного вмешательства.
• Безопасность: Скрытые файлы (как .gitlab/) могут содержать конфиденциальные настройки, которые не должны быть видны случайно при просмотре репозитория.

На практике, при настройке GitLab CI, разработчики чаще всего взаимодействуют с .gitlab-ci.yml и .gitlab/ директорией. Эти элементы образуют основу для современных DevOps-практик, обеспечивая непрерывную интеграцию и доставку. Например, в микросервисной архитектуре каждая точка входа упрощает управление сложными пайплайнами через декларативный YAML-синтаксис.