Типы действий

CreateDefectdojoEngagement

CreateDefectdojoEngagement — создаёт новый engagement в системе DefectDojo. Действие использует DefectDojo API v2.

Пример запроса

name: example engagement
product: '1'
target_start: '2024-06-01'
target_end: '2024-06-30'
lead: '1'

Спецификация запроса

Список полей соответствует официальному API DefectDojo, /api/v2/engagements, подробнее — в документации Defectdojo.

Учётные данные

• token — API v2 Key пользователя, от имени которого будет запускаться выполнение действия.

CreateDefectdojoProduct

CreateDefectdojoProduct — создаёт новый продукт в системе DefectDojo. Действие использует DefectDojo API v2.

Пример запроса

name: example
description: example description
prod_type: 1

Спецификация запроса

Список полей соответствует официальному API DefectDojo, /api/v2/products, подробнее — в документации Defectdojo.

Учётные данные

• token — API v2 Key пользователя, от имени которого будет запускаться выполнение действия.

CreateGitlabBranches

CreateGitlabBranches — создаёт новые ветки в целевом репозитории.

Пример запроса

project_id: '0'
branches:
  - branch: new-branch
    ref: main

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие корректных реквизитов токена GitLab. Этот токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/repository/branches. В случае успешного создания проекта GitLab возвращает информацию о созданных ветках.

CreateGitlabGroupVariables

CreateGitlabGroupVariables — создаёт переменные (variables) на уровне группы в GitLab.

Пример запроса

group_id: '0'
variables:
  - key: EXAMPLE_VARIABLE
    value: value

Спецификация запроса

Список полей для переменных соответствует официальному GitLab Group-level Variables API, /groups/:id/variables, подробнее — в документации Gitlab.

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/groups/:id/variables.

CreateGitlabMergeRequest

CreateGitlabMergeRequest — создаёт новый Merge Request (MR) в целевом репозитории. В Merge Request добавляются файлы, хранящиеся в репозитории-источнике. Файлы могут содержать переменные, значение которых будет подставлено в момент создания MR.

Пример запроса

source_project_id: '0'
source_project_branch: example
source_project_tag: v1.0.0
target_project_id: '0'
merge_request_spec:
  source_branch: example
  target_branch: '1'
  title: example
additionalIgnoreFiles:
  - .ignore
  - .example
values:
  key1: value1
  nested:
    enabled: true
    subkey: 123

Спецификация запроса

Учётные данные

• password — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия.
• username — имя пользователя, от которого будет запускаться выполнение действия.

Алгоритм работы

Платформа:

1. Клонирует репозиторий-шаблон для генерации MR по его идентификатору (source_project_id). Подробнее о шаблонизации.
2. Считывает файл values.yaml, хранящийся в корне репозитория, и определяет переменные по умолчанию для шаблонизации.
3. Считывает переменные, передаваемые при запуске действия, и объединяет (merge) их с переменными из values.yaml. Приоритет отдаётся переменным, передаваемым при запуске действия.
4. Считывает файл .templateignore и определяет директории и файлы, исключаемые из шаблонизации.
5. Рендерит файлы из шаблонов, учитывая values.yaml и переданных в действие переменных.
6. Изменяет удалённый (remote) репозиторий на целевой, согласно его ID (target_project_id), и выполняет git push в целевую ветку (source_project_branch), либо в основную ветку main.
7. Создаёт MR согласно заданным настройкам путём отправки POST-запроса в GitLab API.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/merge_requests.

CreateGitlabProject

CreateGitlabProject — создаёт новый проект в GitLab. Действие осуществляет вызов GitLab API для создания проекта с указанными параметрами, такими как название, путь проекта, описание и другие настройки. Для аутентификации используется GitLab token, который должен быть предоставлен в учётных данных.

Пример запроса

name: example
path: example
description: example
default_branch: main
initialize_with_readme: false
namespace_id: '0'

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects, передавая параметры запроса в формате JSON. В случае успешного создания проекта GitLab возвращает данные о вновь созданном проекте.

CreateGitlabProjectVariables

CreateGitlabProjectVariables — создаёт переменные на уровне проекта в GitLab.

Пример запроса

project_id: '0'
variables:
  - key: EXAMPLE_VARIABLE
    value: value

Спецификация запроса

Список полей для переменных соответствует официальному GitLab Project-level CI/CD variables API, /projects/:id/variables, подробнее — в документации Gitlab.

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/variables.

CreateGitlabProjectWebhook

CreateGitlabProjectWebhook — создаёт вебхук в проекте GitLab.

Пример запроса

project_id: '0'
url: https://example.com
push_events: true
issues_events: true
merge_requests_events: true
pipeline_events: true

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/hooks.

CreateGitlabTag

CreateGitlabTag — создаёт новый тег в проекте GitLab.

Пример запроса

project_id: '0'
tag_name: v1.0.0
ref: main
message: Tag description

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/repository/tags.

CreateGitlabRelease

CreateGitlabRelease — создаёт релиз GitLab на основе уже существующего тега.

Пример запроса

project_id: '0'
tag_name: v1.0.0
name: Release v1.0.0
description: |
  ## Изменения:
  - Новая функция.
  - Исправления ошибок.

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/releases.

CreateKafkaACLs

CreateKafkaACLs — создаёт новый набор ACL в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
acls:
  - topics:
      - example_1
    allow:
      - User:principal_2
      - Group:principal_3
    deny:
      - User:principal_4
      - Group:principal_5
    ops:
      - CREATE
      - READ
      - WRITE
      - DELETE
      - DESCRIBE
      - DESCRIBE_CONFIGS
      - ALTER
    pattern: LITERAL
  - topics:
      - example_6
    allow:
      - User:principal_7
    allow_hosts:
      - 127.0.0.1
    deny:
      - User:principal_8
    deny_hosts:
      - 127.0.0.1
    ops:
      - CREATE
    pattern: LITERAL

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

Список возможных шаблонов

• ANY.
• MATCH.
• LITERAL.
• PREFIXED.

Список возможных операций

Подробнее — в документации Kafka.

Topic:

• ALL.
• ALTER.
• ALTER_CONFIGS.
• CREATE.
• DELETE.
• DESCRIBE.
• DESCRIBE_CONFIGS.
• READ.
• WRITE.

Group:

• ALL.
• DELETE.
• DESCRIBE.
• READ.

TransactionalID:

• ALL.
• DESCRIBE.
• WRITE.

Tokens:

• DESCRIBE.

CreateKafkaTopics

CreateKafkaTopics — создаёт новые топики в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
partitions: 1
replication_factor: 1
configs: {}
topics:
  - example_1
  - example_2

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

CreateKafkaUsers

CreateKafkaUsers — создаёт новых пользователей SASL/SCRAM в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
users:
  - user: example_user_1
    password: example_password_user_1
    mechanism: SCRAM-SHA-256
    iterations: 4096
  - user: example_user_2
    password: example_password_user_2
    mechanism: SCRAM-SHA-256
    iterations: 4096

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

CreateCodeScoringProject

CreateCodeScoringProject — создаёт новый проект в системе CodeScoring. Действие использует CodeScoring API для регистрации проекта с указанными параметрами: название проекта, URL репозитория, ID VCS системы и опция автоматического запуска SCA-анализа после клонирования репозитория.

Пример запроса

name: example-project
repository: https://gitlab.example.com/group/project.git
vcs_id: 2
run_sca_after_clone: true

Спецификация запроса

Ответ

В ответе возвращается объект созданного проекта со следующей информацией: идентификатор проекта (pk), название, тип проекта, описание, информация о репозитории, статус проекта, права доступа, лицензия, количество зависимостей и уязвимостей, языки проекта, статус расписания сканирования и даты первого и последнего SCA-сканирования.

DeleteCodeScoringProject

DeleteCodeScoringProject — удаляет проект в системе CodeScoring по его ID.

Пример запроса

id: 1

Спецификация запроса

CreateKeycloakClient

CreateKeycloakClient — создаёт нового клиента в Keycloak.

Пример запроса

realm: master
config:
  clientId: example
  name: example
  enabled: true
  clientAuthenticatorType: client-secret
  secret: secret
  defaultClientScopes:
  - roles
  - profile
  - email
  optionalClientScopes:
  - address
  - phone
  - offline_access

Спецификация запроса

Учётные данные

• username — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

CreateKubernetesResource

CreateKubernetesResource — создаёт новый ресурс или ресурсы в кластере Kubernetes или обновляет существующие.

Пример запроса

manifests:
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: example1
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: example2

Спецификация запроса

Учётные данные

• token — токен сервисного аккаунта в Kubernetes.

CreateRepositoryFromTemplate

CreateRepositoryFromTemplate — создаёт новый репозиторий из шаблона в Gitlab. Механизм рендеринга основан на Go template и поддерживает все встроенные методы, а также расширения, добавленные в платформу.

Пример запроса

sourceBranch: main
sourceTag: v1.0.0
templateRepositoryUrl: https://gitlab.example.com/example-1.git
targetRepositoryUrl: https://gitlab.example.com/example-2.git
targetBranch: master
additionalIgnoreFiles:
  - .ignore
  - .example
values:
  key1: value1
  nested:
    enabled: true
    subkey: 123

Спецификация запроса

Учётные данные

• password — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия.
• username — имя пользователя, от которого будет запускаться выполнение действия.

Алгоритм работы

Платформа:

1. Клонирует шаблонный репозиторий по указанному URL (templateRepositoryUrl), используя в качестве ref либо sourceTag, либо sourceBranch, либо ветку main.
2. Считывает файл values.yaml, хранящийся в корне репозитория, и определяет переменные по умолчанию для шаблонизации.
3. Считывает переменные, передаваемые при запуске действия, и делает их merge с переменными из values.yaml. Приоритет при merge отдаётся переменным, передаваемым при запуске действия.
4. Считывает файл .templateignore и определяет директории и файлы, исключаемые из шаблонизации.
5. Рендерит из шаблонов файлы, учитывая values.yaml и переданные в действие переменные.
6. Изменяет удалённый (remote) репозиторий на целевой (targetRepositoryUrl) и делает git push в целевую ветку (targetBranch), либо в основную ветку main.

Детали работы

Действие поддерживает шаблонизацию имён директорий и файлов. Для этого необходимо в их название добавить выражение в формате Go template. Например, директория src/{{ .module }}/utils при наличии value module со значением example будет отрендерена в директорию src/example/utils в целевом репозитории.

Если после рендеринга из шаблона содержимое файла будет отсутствовать, файл не создаётся. Например, файл с содержимым:

{{- if .createContent }}
- Это контент, который будет отображаться, если переменная createContent == true
{{- end }}

не будет создан, если переменная createContent имеет значение false. Аналогичным образом, не будут созданы файлы, изначально являющиеся пустыми.

При отсутствии переменных для шаблонизации одновременно в файле values.yaml и в переменных, передаваемых при запуске действия, рендеринг завершится с ошибкой и целевой репозиторий создан не будет.

Переменные шаблонного репозитория

Для добавления переменных по умолчанию, используемых при шаблонизации, необходимо создать в корне репозитория файл values.yaml с соответствующим содержимым.

Пример файла values.yaml:

module: example
createContent: false

Файл values.yaml является опциональным.

Исключение файлов

Некоторые файлы могут содержать переменные в формате Go template, которые необходимо сохранять при рендеринге репозитория из шаблона, например, Helm-чарты в директории helm. Директория .git игнорируется всегда.

Для исключения подобных файлов из механизма рендеринга следует добавить в корень репозитория файл .templateignore с соответствующим содержимым.

В каждой строке .templateignore задаётся одно правило — путь или маска. Если в строке есть {{, вся строка выполняется как один шаблон Go с теми же переменными и функциями, что при подстановке в имена файлов и каталогов (подробнее — «Как обрабатывается строка правила»). Если {{ в строке нет, подстановка переменных из values.yaml и из запроса действия не делается: строка читается как есть и сравнивается с относительным путём на диске, допускаются литералы и символы маски * и **.

Пример файла .templateignore только с масками пути, без шаблонов подстановки, для игнорирования содержимого директорий helm, docs:

helm/**
docs/**

Добавление путей в игнор

1. В корне шаблонного репозитория создайте или отредактируйте файл .templateignore (по одному правилу на строку).

2. Каждая строка — это одно правило: путь от корня репозитория. В нём допускаются обычные символы пути и маски: звёздочка * в имени сегмента, последовательность ** — для произвольной глубины вложенных каталогов. Платформа сопоставляет относительный путь с маской по встроенным правилам (аналогично распространённым соглашениям для масок в файлах игнорирования в системах контроля версий).

3. Чтобы подставить фрагмент пути из values.yaml или из поля values запроса действия, используйте в строке конструкции Go template ({{ ... }}). Если в строке есть {{, платформа обрабатывает всю строку от начала до конца как один шаблон Go: нельзя оставить часть строки «простым текстом» и шаблонизировать только середину пути. Примеры — в разделе «Примеры Go template в .templateignore».

4. Пустые строки и строки, начинающиеся с #, при разборе файла пропускаются — их можно использовать для комментариев.

Примеры без подстановки (только маски пути)

Отдельные файлы в корне:

package-lock.json
yarn.lock
LICENSE
.env.local

Каталоги целиком и типичные артефакты сборки:

vendor/**
node_modules/**
dist/**
build/tmp/**

Вложенность по маске:

docs/**/*.pdf
charts/*/values.schema.json
.github/workflows/**

Секреты по расширению во всём дереве:

**/*.pem
**/*.key

Как обрабатывается строка правила

Переменные для раскрытия правил те же, что объединены из values.yaml в корне шаблонного репозитория и из поля values в запросе действия (приоритет у values в запросе).

Для каждой непустой строки из .templateignore или из файла из additionalIgnoreFiles платформа делает следующее.

1. В список правил всегда попадает строка как в файле, без изменений. Именно её потом сравнивают с путём к файлу в первую очередь — это нужно, когда в именах на диске ещё есть фрагменты вроде {{ .module }} до переименования.

2. Если в строке есть {{, платформа один раз прогоняет всю строку через шаблонизатор Go template с теми же возможностями, что при подстановке в имена файлов и каталогов (встроенные функции платформы и набор Sprig). Если {{ в строке нет, этот шаг пропускают.

3. Если шаг подстановки был и полученный текст отличается от строки в файле (включая случай «на выходе пусто»), в список правил добавляют вторую запись — уже с этим полученным текстом. Итого из одной строки файла может получиться две записи в списке. При проверке пути к файлу смотрят обе: достаточно совпадения с любой из них — файл попадает под правило.

Дальше при обходе дерева для каждого пути к файлу вычисляется путь относительно корня клонированной копии (с прямыми слешами). Путь сравнивается с каждым правилом: сначала по правилам сопоставления с маской (в том числе с использованием * и **), при необходимости — по точному совпадению строки правила и относительного пути.

Так одна строка в файле может задать два правила: например, исходное charts/{{ .name }}/** (чтобы не трогать путь до переименования каталогов), и раскрытое charts/billing/** (чтобы совпадало с путём после подстановки переменных в имена на диске). Поэтому правила работают и «до», и «после» этапа переименования каталогов по шаблону.

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

Поле additionalIgnoreFiles в действии задаёт имена дополнительных файлов в корне репозитория; в каждом из них — такие же строки-правила, как в .templateignore, с тем же раскрытием шаблонов. Но смысл другой: совпавшие пути убирают из рабочей копии (каталог или файл удаляют), и делают это дважды — в начале и в конце цепочки обработки, чтобы эти объекты не участвовали в дальнейших шагах и не попали в итоговый репозиторий.

Файл .templateignore, наоборот, означает «не шаблонизировать»: для совпавших путей платформа не подставляет переменные в содержимое файлов и не применяет к соответствующим каталогам переименование по шаблону в пути. Сами файлы и каталоги при этом не удаляются только из‑за записи в .templateignore — они остаются в копии, но обрабатываются как обычный текст и обычные имена, без шага шаблонизации.

Примеры Go template в .templateignore

Ниже в каждом примере показаны фрагменты values.yaml (или эквивалентные поля в values запроса) и строки .templateignore. Несколько независимых правил задают несколькими строками файла: результат одной строки-шаблона — одна строка с маской; перевод строк внутри результата шаблона не делит правило на несколько.

Имя каталога в правиле берётся из values.yaml или из values действия:

values.yaml:

project: payment-gateway

.templateignore:

{{ .project }}/legacy/**

В набор правил попадут строки {{ .project }}/legacy/** и payment-gateway/legacy/**.

Сегмент пути из переменной и статический хвост:

values.yaml:

lang: ru

.templateignore:

apps/{{ .lang }}/messages.yaml

Условное правило в одной строке работает следующим образом: при skipGenerated: false подстановка даёт пустую строку, которая всё равно добавляется вторым правилом. Исходная строка с {{ используется как маска пути и обычно не совпадает с реальными путями. При skipGenerated: true вторым правилом становится generated/**):

values.yaml:

skipGenerated: false

.templateignore:

{{- if .skipGenerated }}generated/**{{- end }}

Вариант «игнорировать только не production»:

values.yaml:

tier: staging

.templateignore:

{{- if ne .tier "prod" }}mock/**{{- end }}

Использование printf для сборки строки маски (удобно, если имя чарта в переменной):

values.yaml:

chartName: wordpress

.templateignore:

{{ printf "charts/%s/**" .chartName }}

Значение по умолчанию для «пустого» значения — функция default из набора Sprig. Поле в данных должно существовать (иначе при раскрытии сработает missingkey=error); для «не задано в YAML» заведите ключ с пустой строкой или используйте условие if / index:

values.yaml:

envName: ""

.templateignore:

{{ default "dev" .envName }}/secrets/**

При пустом envName в правило попадёт и {{ default "dev" .envName }}/secrets/**, и dev/secrets/**.

Опциональный сегмент пути (with):

values.yaml:

analyticsModule: tracking

.templateignore:

{{ with .analyticsModule }}{{ . }}/vendor/**{{ end }}

Если analyticsModule пусто, шаблон даёт пустую строку (см. правила раскрытия выше).

Доступ к полю вложенной структуры по строковому ключу index:

values.yaml:

regions:
  primary: eu-west

.templateignore:

configs/{{ index .regions "primary" }}/bootstrap.yaml

Удаление пробелов в сегменте имени — функция trim из набора Sprig:

values.yaml:

serviceName: " billing-api "

.templateignore:

{{ trim .serviceName " " }}/logs/**

Несколько фрагментов в одной маске:

values.yaml:

base: services
variant: canary

.templateignore:

{{ .base }}/{{ .variant }}/**/*.tmp

Примеры для additionalIgnoreFiles

В спецификации действия перечисляются имена файлов в корне репозитория (например, .ship-ignore, .ci-remove). Формат строк внутри таких файлов тот же: комментарии #, пустые строки, маски пути, при необходимости — шаблоны Go в строках.

Файл .ship-ignore в шаблоне:

# не попадает в целевой репозиторий
local/fixtures/**
scratchpad.md

Фрагмент запроса действия:

additionalIgnoreFiles:
  - .ship-ignore

Шаблон в файле для additionalIgnoreFiles (удаление каталога, имя из переменных):

Файл .env-drop в корне шаблона:

{{ .obsoleteDir }}/**

При obsoleteDir: legacy-ui из values после раскрытия в списке удаления окажутся и {{ .obsoleteDir }}/**, и legacy-ui/** — совпавшие пути будут удалены из копии перед финальными шагами.

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

├── example-folder-01
│   ├── example-file-01
│   └── {{ .example }}-file-02
├── {{ .example }}-folder-02
│   └── ...
├── values.yaml
└── .templateignore

Если переменная example при рендере репозитория примет значение new, то итоговая структура после рендера будет выглядеть следующим образом:

├── example-folder-01
│   ├── example-file-01
│   └── new-file-02
├── new-folder-02
│   └── ...
├── values.yaml
└── .templateignore

Локальная отладка

Для локальной отладки шаблонов доступна утилита ddp-render-dir.

Утилита:

1. Создаёт копию исходной директории.
2. Выполняет рендеринг файлов в этой директории по тем же правилам, что и действие создания репозиториев из шаблонов.

Ключи командной строки для запуска:

• --source-dir — исходная директория, которую необходимо отрендерить.
• --target-dir — директория, в которую будет помещен результат рендеринга.
• --values (опционально) — путь к файлу values.yaml с переменными, которые будут использоваться при рендеринге.
• --ignore-files (опционально) — список файлов, содержащих пути для исключения из целевого репозитория.

CreateSonarqubeProject

CreateSonarqubeProject — создаёт новый проект в SonarQube. Действие использует SonarQube Web API для создания проекта с указанными параметрами, такими как ключ (project key), название проекта, главная ветка, параметры определения нового кода (new code definition) и видимость проекта. Аутентификация осуществляется с использованием SonarQube token, который должен быть передан в учётных данных.

Пример запроса

project: example-project
name: example-project
mainBranch: develop
newCodeDefinitionType: NUMBER_OF_DAYS
newCodeDefinitionValue: '30'
visibility: public

Спецификация запроса

Учётные данные

• token — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия.

CreateVaultSecret

CreateVaultSecret — создаёт секрет с одним или несколькими значениями в HashiCorp Vault.

Пример запроса

path: example/data/path
secrets:
  - key: key1
    value: value1
  - key: key2
    value: value2

Спецификация запроса

Учётные данные

• token — Vault-токен, который имеет необходимые права для создания секретов.

Примечание

allow_update — определяет поведение действия при создании или обновлении секрета:

• false (по умолчанию) — действие завершается с ошибкой, если секрет уже существует;
• true — создаётся новая версия секрета со значениями, переданными в действии;
• merge — обновляются или создаются только те ключи секрета, которые указаны в действии. Существующие ключи, не упомянутые в действии, сохраняются без изменений. Если секрета по пути ещё нет, действие завершается с ошибкой;
• merge_or_create — как merge, если секрет уже существует; если секрета по пути нет, он создаётся (полная запись значений из действия).

DeleteVaultSecret

DeleteVaultSecret — удаляет секрет из HashiCorp Vault.

Пример запроса

path: example/data/path

Спецификация запроса

Учётные данные

• token — Vault-токен, который имеет необходимые права для удаления секретов.

DeleteDefectdojoProduct

DeleteDefectdojoProduct — удаляет продукт из DefectDojo. Действие использует DefectDojo API v2.

Пример запроса

id: 1

Спецификация запроса

Учётные данные

• token — API v2 Key пользователя, от имени которого будет запускаться выполнение действия.

DeleteGitlabProject

DeleteGitlabProject — удаляет существующий проект в GitLab. Действие осуществляет вызов GitLab API для удаления проекта. Для аутентификации используется GitLab token, который должен быть предоставлен в учётных данных.

Пример запроса

project_id: 0

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет DELETE-запрос по URL: /api/v4/projects/:id.

DeleteKafkaACLs

DeleteKafkaACLs — удаляет набор ACL в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
acls:
  - topics:
      - example_1
    allow:
      - User:principal_2
      - Group:principal_3
    allow_hosts:
      - 127.0.0.1
    deny:
      - User:principal_4
      - Group:principal_5
    deny_host:
      - 127.0.0.1
    ops:
      - CREATE
      - READ
      - WRITE
      - DELETE
      - DESCRIBE
      - DESCRIBE_CONFIGS
      - ALTER
    pattern: LITERAL
  - any_topic: true
    any_group: true
    any_transactional_id: true
    any_allow: true
    any_allow_hosts: true
    any_deny: true
    any_deny_hosts: true
    ops:
      - ANY
    pattern: ANY
  - any_resource: true
    any_allow: true
    any_allow_hosts: true
    any_deny: true
    any_deny_hosts: true
    ops:
      - ANY
    pattern: ANY

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

Список возможных pattern

• ANY.
• MATCH.
• LITERAL.
• PREFIXED.

Список возможных операций

Подробное описание — в документации Kafka.

Topic:

• ALL.
• ALTER.
• ALTER_CONFIGS.
• CREATE.
• DELETE.
• DESCRIBE.
• DESCRIBE_CONFIGS.
• READ.
• WRITE.

Group:

• ALL.
• DELETE.
• DESCRIBE.
• READ.

TransactionalID:

• ALL.
• DESCRIBE.
• WRITE.

Token:

• DESCRIBE.

DeleteKafkaTopics

DeleteKafkaTopics — удаляет существующие топики в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
topics:
  - example_1
  - example_2

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

DeleteKafkaUsers

DeleteKafkaUsers — удаляет существующих пользователей SASL/SCRAM в Kafka.

Пример запроса

securityProtocol: SASL_PLAINTEXT
saslMechanism: PLAIN
users:
  - user: example_user_1
    mechanism: SCRAM-SHA-256
  - user: example_user_2
    mechanism: SCRAM-SHA-256

Спецификация запроса

Учётные данные

• user — имя пользователя, от которого будет запускаться выполнение действия.
• password — пароль пользователя, от имени которого будет запускаться выполнение действия.

DeleteKubernetesResource

DeleteKubernetesResource — удаляет существующий ресурс в кластере Kubernetes.

Пример запроса

group: apps
version: v1
resource_type: deployments
resource_name: nginx-deployment
namespace: example

Спецификация запроса

Учётные данные

• token — токен сервисного аккаунта в Kubernetes.

Определение требуемых Group и Version

Каждому типу ресурса соответствует своя группа API (Group) и версия (Version). Полный список API-ресурсов с их группами и версиями приведён в документации Kubernetes.

Если неизвестно, какие требуются Group и Version, можно использовать актуальные значения. Существует несколько способов их определить:

С помощью утилиты d8 k

Команда d8 k explain показывает apiVersion для ресурса.

Пример:

d8 k explain deployment

Вывод:

GROUP:      apps
KIND:       Deployment
VERSION:    v1

DESCRIPTION:
    Deployment enables declarative updates for Pods and ReplicaSets.
    
FIELDS:
...

С помощью документации

Как искать в документации:

1. Найдите нужный ресурс (например, Deployment).

2. В заголовке будет указана API Group и версия. Пример для Deployment:

   apiVersion: apps/v1

   Здесь:

   • «API Group» — apps;
   • «Version» — v1.

DeleteSonarqubeProject

DeleteSonarqubeProject — удаляет проект из SonarQube.

Пример запроса

project: example-project

Спецификация запроса

Учётные данные

• token — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия.

DeleteSonarqubeProjects

DeleteSonarqubeProjects — удаляет один или несколько проектов из SonarQube.

Пример запроса

analyzedBefore: 2017-10-19T13:00:00+0200
onProvisionedOnly: 'false'
projects: example_project,another_project
q: example
qualifiers: TRK

Спецификация запроса

Учётные данные

• token — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия.

StartGitlabPipeline

StartGitlabPipeline — запускает выполнение пайплайна в GitLab.

Пример запроса

project_id: 0
ref: main
variables:
  - key: example-key
    value: example-value

Спецификация запроса

Учётные данные

• token — токен пользователя, от имени которого будет запускаться выполнение действия.

Примечание

Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок Private-Token).

Действие осуществляет POST-запрос по URL: /api/v4/projects/:id/pipeline.

CreateVaultKubernetesAuthRole

CreateVaultKubernetesAuthRole — создаёт или обновляет роль аутентификации Kubernetes в HashiCorp Vault.

Пример запроса

mountPath: kubernetes
role: example
bound_service_account_names:
  - default
bound_service_account_namespaces:
  - default
optional:
  token_ttl: 1h
  token_max_ttl: 12h
  audience: vault
  token_policies:
    - default

Спецификация запроса

Поддерживаемые значения в optional:

Полный список поддерживаемых параметров приведён в официальной документации HashiCorp Vault.

Учётные данные

• token — Vault-токен, обладающий правами на создание/обновление ролей Kubernetes auth backend.

CreateNexusRepository

CreateNexusRepository — создаёт новый репозиторий любого поддерживаемого типа (maven, docker, npm и др.) в Nexus Repository Manager 3 с помощью REST API.
Параметры формата, типа и другие ключевые настройки полностью настраиваются и соответствуют Nexus API.

Пример запроса (Maven hosted)

description: |
  Maven hosted repo for internal Java build artifacts.
name: my-maven-repo
format: maven
type: hosted
online: true
storage:
  blobStoreName: default
  strictContentTypeValidation: true
  writePolicy: ALLOW
cleanup:
  policyNames:
    - maven-cleanup
maven:
  versionPolicy: RELEASE
  layoutPolicy: PERMISSIVE

Пример запроса (Docker group)

description: |
  Docker group repo aggregating hosted+proxy.
name: my-docker-group
format: docker
type: group
online: true
storage:
  blobStoreName: default
  strictContentTypeValidation: true
group:
  memberNames:
    - docker-hosted
    - docker-proxy
docker:
  v1Enabled: false
  forceBasicAuth: true
  httpPort: 5001

Спецификация запроса

Требования

• Используйте только те блоки (maven, group, proxy, docker и пр.), которые поддерживаются для вашего типа/формата.
• Для maven hosted обязательно maven: {versionPolicy, layoutPolicy}.
• Для group — обязательно group.memberNames.
• Для proxy — обязательно proxy.remoteUrl.
• Для docker — специфичные поля в docker.

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

DeleteNexusRepository

DeleteNexusRepository — удаляет существующий репозиторий из Nexus Repository Manager 3.

Пример запроса

name: my-repo-to-delete

Спецификация запроса

Алгоритм

• Выполняется DELETE по адресу /service/rest/v1/repositories/{name}, где {name} — это значение поля name.
• Если репозиторий найден и удалён — возвращается 204.
• Если не найден — возвращается ошибка 404.

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

CreateNexusPrivilege

CreateNexusPrivilege — создаёт новую привилегию в Nexus Repository Manager 3. Привилегии определяют права доступа к репозиториям и другим ресурсам Nexus.

Пример запроса (repository-view)

name: example-privilege
description: Example privilege description
type: repository-view
actions:
  - READ
  - BROWSE
format: maven2
repository: maven-releases

Пример запроса (repository-content-selector)

name: content-selector-privilege
description: Privilege with content selector
type: repository-content-selector
actions:
  - READ
format: maven2
repository: maven-releases
contentSelector: my-content-selector

Пример запроса (wildcard)

name: wildcard-privilege
description: Wildcard privilege
type: wildcard
pattern: nx-*
actions:
  - READ

Спецификация запроса

Примечание

Для типа repository-content-selector селектор контента должен существовать в Nexus до создания привилегии. Если селектор контента не указан или невалиден, действие автоматически преобразует тип привилегии в repository-view.

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

AssignNexusPrivilege

AssignNexusPrivilege — назначает привилегии существующей роли в Nexus Repository Manager 3. Действие получает текущую конфигурацию роли и объединяет существующие привилегии с новыми.

Пример запроса

roleId: example-role
privileges:
  - example-privilege
  - another-privilege

Спецификация запроса

Алгоритм работы

1. Получает текущую конфигурацию роли из Nexus.
2. Объединяет существующие привилегии роли с новыми привилегиями из запроса.
3. Обновляет роль с объединённым списком привилегий.

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

Примечание

Роль должна существовать в Nexus до назначения привилегий. Если роль не найдена, действие завершится с ошибкой. Все указанные привилегии также должны существовать в Nexus.

DeleteNexusPrivilege

DeleteNexusPrivilege — удаляет привилегию из Nexus Repository Manager 3.

Пример запроса

name: example-privilege

Спецификация запроса

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

CreateNexusRole

CreateNexusRole — создаёт новую роль в Nexus Repository Manager 3. Роли объединяют привилегии и могут включать другие роли.

Пример запроса

id: example-role
name: Example Role
description: Example role description
privileges:
  - nx-repository-view-*-*-read
  - nx-repository-view-maven2-*-browse
roles: []

Спецификация запроса

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

AssignNexusRole

AssignNexusRole — назначает роли существующему пользователю в Nexus Repository Manager 3. Действие получает текущую конфигурацию пользователя и объединяет существующие роли с новыми.

Пример запроса

userId: example-user
roles:
  - example-role
  - another-role

Спецификация запроса

Алгоритм работы

1. Получает текущую конфигурацию пользователя из Nexus.
2. Объединяет существующие роли пользователя с новыми ролями из запроса.
3. Обновляет пользователя с объединённым списком ролей.

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

Примечание

Пользователь должен существовать в Nexus до назначения ролей. Если пользователь не найден, действие завершится с ошибкой. Все указанные роли также должны существовать в Nexus.

DeleteNexusRole

DeleteNexusRole — удаляет роль из Nexus Repository Manager 3.

Пример запроса

id: example-role

Спецификация запроса

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

CreateNexusUser

CreateNexusUser — создаёт нового пользователя в Nexus Repository Manager 3.

Пример запроса

userId: example-user
firstName: First
lastName: Last
emailAddress: user@example.com
password: password
status: active
roles:
  - nx-admin

Спецификация запроса

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

DeleteNexusUser

DeleteNexusUser — удаляет пользователя из Nexus Repository Manager 3.

Пример запроса

userId: example-user

Спецификация запроса

Учётные данные

• token — строка base64(admin:password), используется как Basic Auth при запросах к Nexus.

Wait

Wait ожидает заданное число секунд; дополнительно может применяться случайная добавка к длительности (джиттер). Предназначено для использования в процессах в качестве элемента задержки, в том числе для ожидания применения результатов предыдущего действия.

Пример запроса

duration_seconds: 10
max_jitter_seconds: 0
description: "Waiting for release"

Спецификация запроса

Fail

Fail эмулирует ошибку исполнения действия. Предназначен для использования в процессах в качестве отладочного элемента.

Пример запроса

fail: true

Спецификация запроса