CI/CD: рецепты

Коллекция Endpoint — это обычная папка в Git, поэтому её можно запускать в любом CI. Ниже готовые фрагменты для типичных схем: копируйте и меняйте пути, ветки и окружения. Описание всех флагов — в разделе CLI.

Установка CLI одной командой

Скрипт сам определяет ОС и архитектуру (x64, ARM64), скачивает endpoint-cli и проверяет SHA-256.

# Linux и macOS (нужен curl или wget)
curl -fsSL https://endpoint.ll.kg/install-cli.sh | sh

# зафиксировать версию (рекомендуется для CI) и/или папку установки
curl -fsSL https://endpoint.ll.kg/install-cli.sh | ENDPOINT_VERSION=0.5.0 ENDPOINT_INSTALL_DIR=. sh

# Windows (PowerShell)
irm https://endpoint.ll.kg/install-cli.ps1 | iex

По умолчанию CLI ставится в /usr/local/bin (или ~/.local/bin, если нет прав), на Windows — в %LOCALAPPDATA%\endpoint-cli. Бинарник статический: работает в alpine, debian, ubuntu и любом другом образе.

Без скрипта — прямые ссылки на последнюю версию:

curl -fsSL -o endpoint-cli https://endpoint-dl.ll.kg/latest/endpoint-cli-linux-amd64   # или linux-arm64, darwin-arm64…
chmod +x endpoint-cli

Как устроен запуск

endpoint-cli run <папка коллекции> -e <окружение> [--folder <папка>] [--var key=value] --junit report.xml

Код выхода: 0 — всё прошло, 1 — упали тесты или запросы (CI пометит задачу красной), 2 — ошибка запуска (нет окружения, неверный флаг).
Секреты не хранятся в Git. Передайте их переменными CI: переменная окружения коллекции token берётся из ENDPOINT_VAR_TOKEN, api-key — из ENDPOINT_VAR_API_KEY.
--var перекрывает значение из окружения, например адрес стенда: --var baseUrl=$API_URL.
--folder users запускает только папку, --bail останавливает прогон на первой ошибке.

1. Коллекция в том же репозитории и той же ветке

Самый простой вариант: папка api/ лежит рядом с кодом.

GitLab CI

api-tests:
  image: alpine:3.22
  variables:
    ENDPOINT_VERSION: "0.5.0"
  before_script:
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - endpoint-cli run ./api -e staging --junit report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

Секрет ENDPOINT_VAR_TOKEN добавьте в Settings → CI/CD → Variables (Masked). Отчёт появится во вкладке Tests пайплайна и в merge request.

GitHub Actions

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: curl -fsSL https://endpoint.ll.kg/install-cli.sh | ENDPOINT_VERSION=0.5.0 sh
      - run: endpoint-cli run ./api -e staging --junit report.xml
        env:
          ENDPOINT_VAR_TOKEN: ${{ secrets.API_TOKEN }}
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: api-report
          path: report.xml

2. Коллекция в другой ветке того же репозитория

Типичная схема Endpoint: код в master, запросы — в ветке endpoint (или api-tests). Пайплайн кода забирает коллекцию из соседней ветки.

Любой CI (git): подтянуть только нужную ветку в отдельную папку, не трогая текущий checkout:

git fetch --depth 1 origin endpoint
git worktree add ../api-tests FETCH_HEAD
endpoint-cli run ../api-tests/api -e staging --junit report.xml

GitLab CI

api-tests:
  image: alpine:3.22
  variables:
    COLLECTION_BRANCH: endpoint
  before_script:
    - apk add --no-cache git
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - git fetch --depth 1 origin "$COLLECTION_BRANCH"
    - git worktree add /tmp/api-tests FETCH_HEAD
    - endpoint-cli run /tmp/api-tests/api -e staging --junit report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

GitHub Actions — второй checkout в отдельную папку:

    steps:
      - uses: actions/checkout@v7            # код
      - uses: actions/checkout@v7            # коллекция из ветки endpoint
        with:
          ref: endpoint
          path: api-tests
      - run: curl -fsSL https://endpoint.ll.kg/install-cli.sh | sh
      - run: endpoint-cli run ./api-tests/api -e staging --junit report.xml
        env:
          ENDPOINT_VAR_TOKEN: ${{ secrets.API_TOKEN }}

Чтобы проверять ту ветку коллекции, в которой вы сейчас работаете (например feature/orders), передайте её переменной: в GitLab — Run pipeline → Variables → COLLECTION_BRANCH, в GitHub — workflow_dispatch с параметром и ref: ${{ inputs.branch }}.

3. Коллекция в другом репозитории

Коллекция живёт отдельно (например qa/api-collection), а тесты запускаются из пайплайна сервиса.

GitLab CI — через CI_JOB_TOKEN, без отдельных паролей:

api-tests:
  image: alpine:3.22
  variables:
    COLLECTION_REPO: qa/api-collection
    COLLECTION_BRANCH: master
  before_script:
    - apk add --no-cache git
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - git clone --depth 1 --branch "$COLLECTION_BRANCH" "https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}/${COLLECTION_REPO}.git" /tmp/collection
    - endpoint-cli run /tmp/collection -e staging --junit report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

В проекте с коллекцией разрешите доступ: Settings → CI/CD → Job token permissions → Add project и укажите проект сервиса. Если так нельзя, создайте Deploy token (read_repository), положите его в переменные CI и клонируйте по адресу https://<user>:${DEPLOY_TOKEN}@${CI_SERVER_HOST}/qa/api-collection.git.

GitHub Actions — нужен токен с правом чтения второго репозитория (fine-grained PAT с Contents: Read или токен GitHub App):

    steps:
      - uses: actions/checkout@v7
        with:
          repository: Keremet-DEV/api-collection
          ref: master
          token: ${{ secrets.COLLECTION_TOKEN }}
          path: collection
      - run: curl -fsSL https://endpoint.ll.kg/install-cli.sh | sh
      - run: endpoint-cli run ./collection -e staging --junit report.xml
        env:
          ENDPOINT_VAR_TOKEN: ${{ secrets.API_TOKEN }}

Любой другой CI — токен передаётся заголовком и не попадает в адрес и логи:

git -c http.extraHeader="Authorization: Bearer $GIT_TOKEN" \
  clone --depth 1 --branch master https://git.example.com/qa/api-collection.git collection
endpoint-cli run ./collection -e staging

4. Прогон после деплоя: сервис запускает тесты в репозитории коллекции

Сервис задеплоился → запускается пайплайн репозитория с коллекцией и проверяет свежий стенд. Результат виден в обоих пайплайнах.

GitLab CI — в .gitlab-ci.yml сервиса:

api-tests:
  stage: verify            # после deploy
  trigger:
    project: qa/api-collection
    branch: master
    strategy: depend       # пайплайн сервиса ждёт результат тестов
  variables:
    API_URL: https://staging.example.com

В репозитории коллекции:

run:
  image: alpine:3.22
  before_script:
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - endpoint-cli run . -e staging --var baseUrl="${API_URL:-https://staging.example.com}" --junit report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

GitHub Actions — сервис отправляет событие:

      - name: Trigger API tests
        env:
          GH_TOKEN: ${{ secrets.COLLECTION_TOKEN }}   # нужно право Contents: Read and write
        run: gh api repos/Keremet-DEV/api-collection/dispatches -f event_type=deployed -F "client_payload[api_url]=https://staging.example.com"

а репозиторий коллекции его принимает:

on:
  repository_dispatch:
    types: [deployed]
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: curl -fsSL https://endpoint.ll.kg/install-cli.sh | sh
      - run: endpoint-cli run . -e staging --var "baseUrl=${{ github.event.client_payload.api_url }}" --junit report.xml

5. Проверка merge request в репозитории коллекции

Каждое изменение запросов и тестов проверяется до слияния в master:

api-tests:
  image: alpine:3.22
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  before_script:
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - endpoint-cli run . -e staging --junit report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

6. Несколько окружений и регулярные smoke-тесты

GitLab CI — матрица и расписание (Build → Pipeline schedules, например каждый час):

smoke:
  image: alpine:3.22
  parallel:
    matrix:
      - ENV: [dev, staging, prod]
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  before_script:
    - wget -qO- https://endpoint.ll.kg/install-cli.sh | sh
  script:
    - endpoint-cli run . -e "$ENV" --folder smoke --bail --junit "report-$ENV.xml"
  artifacts:
    when: always
    reports:
      junit: report-*.xml

GitHub Actions:

on:
  schedule:
    - cron: "0 * * * *"
jobs:
  smoke:
    strategy:
      fail-fast: false
      matrix:
        env: [dev, staging, prod]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: curl -fsSL https://endpoint.ll.kg/install-cli.sh | sh
      - run: endpoint-cli run . -e ${{ matrix.env }} --folder smoke --bail

7. Корпоративная сеть: свой CA, прокси, mTLS

Сертификаты удобно хранить в CI-переменной типа File: GitLab подставит путь к файлу.

endpoint-cli run . -e staging \
  --cacert "$CORP_CA" \
  --proxy http://proxy.corp:3128 --no-proxy-for "localhost,.corp.lan" \
  --pfx "$CLIENT_PFX" --pfx-pass "$CLIENT_PFX_PASS"

Если и Git-сервер использует внутренний CA, дайте его git: export GIT_SSL_CAINFO="$CORP_CA". --insecure отключает проверку TLS — используйте его только на тестовых стендах.

8. Docker, Jenkins и другие CI

Без установки на хост — одноразовый контейнер:

docker run --rm -v "$PWD:/w" -w /w -e ENDPOINT_VAR_TOKEN alpine:3.22 \
  sh -c "wget -qO- https://endpoint.ll.kg/install-cli.sh | sh && endpoint-cli run ./api -e staging --junit report.xml"

Jenkins (declarative pipeline):

stage('API tests') {
  environment { ENDPOINT_VAR_TOKEN = credentials('api-token') }
  steps {
    sh 'curl -fsSL https://endpoint.ll.kg/install-cli.sh | ENDPOINT_INSTALL_DIR=. sh'
    sh './endpoint-cli run ./api -e staging --junit report.xml'
  }
  post { always { junit 'report.xml' } }
}

Windows-раннер (PowerShell):

irm https://endpoint.ll.kg/install-cli.ps1 | iex
endpoint-cli run .\api -e staging --junit report.xml

Отчёты

Флаг	Что получится
`--junit report.xml`	JUnit XML: вкладка Tests в GitLab, `junit` в Jenkins, test reporter в GitHub
`--json result.json`	все запросы, статусы, время и результаты тестов — для своих дашбордов
`-v`	вывод `console.log` из скриптов прямо в лог задачи
`--no-color`	лог без цветовых кодов (если CI их не поддерживает)