Nexus cd что это

Как использовать репозиторий Nexus и Helm для CI / CD

Добавьте репозиторий Nexus в конфигурацию Helm, используя скопированный сертификат:

sudo helm repo add --ca-file ~/ca.crt nexus https://nexus_user:nexus_pass@nexus.domain.ru/repository/helm-hosted/ "nexus" has been added to your repositories

Теперь у вас есть доступ в репозиторий.

Пушинг Helm Chart в Nexus

Чтобы запушить ваш чарт в Nexus, мы сначала его упакуем, а затем загрузим чарт с помощью curl в репозиторий, который мы уже добавили в Helm.

helm package

На выходе вы получите запакованный чарт my-chart-0.1.0.tgz.

Отправка чарта в Nexus:

curl --insecure -v -F file=@max-0.1.0.tgz -u nexus_user:nexus_pass https://nexus.domain.ru/service/rest/v1/components?repository=helm-hosted

На выходе вы получите примерно такое сообщение:

 * About to connect() to nexus.domain.ru port 443 (#0) * Trying 172.24.26.82. * Connected to nexus.domain.ru (172.24.26.82) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 * Server certificate: * subject: CN=*.domain.ru * start date: Aug 18 00:00:00 2021 GMT * expire date: Aug 18 23:59:59 2022 GMT * common name: *.domain.ru * issuer: CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB * Server auth using Basic with user 'rosreestr_pusher' > POST /service/rest/v1/components?repository=helm-hosted HTTP/1.1 > Authorization: Basic cm9zcmVlc3RyX3B1c2hlcjpuZXh1czRyZnY= > User-Agent: curl/7.29.0 > Host: nexus.domain.ru > Accept: */* > Content-Length: 3953 > Expect: 100-continue > Content-Type: multipart/form-data; boundary=----------------------------c3b97531c3de > < HTTP/1.1 100 Continue < HTTP/1.1 204 No Content < Server: nginx/1.20.1 < Date: Sun, 10 Oct 2021 14:06:14 GMT < Connection: keep-alive < X-Content-Type-Options: nosniff < * Connection #0 to host nexus.domain.ru left intact

Убеждаемся, что наш чарт в репозитории:

Установка Helm чарта из Nexus

Чтобы установить Helm чарт из Nexus, вам необходимо обновить индекс репозитория, чтобы были доступны latest пакеты на Nexus, используя helm repo update, а затем helm install, чтобы создать новый релиз из чарта.

$ helm repo update Hang tight while we grab the latest from your chart repositories. . Successfully got an update from the "gitlab" chart repository Update Complete. ⎈Happy Helming!⎈

$ helm install nexusrepo/ --version 0.1.0

На выходе получим:

$ sudo helm install max-ko nexus/max --version 0.1.0 NAME: max-ko LAST DEPLOYED: Sun Oct 10 17:36:31 2021 NAMESPACE: rr STATUS: deployed REVISION: 1 NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace rr -l "app.kubernetes.io/name=max,app.kubernetes.io/instance=max-ko" -o jsonpath="") export CONTAINER_PORT=$(kubectl get pod --namespace rr $POD_NAME -o jsonpath="") echo "Visit http://127.0.0.1:8080 to use your application" kubectl --namespace rr port-forward $POD_NAME 8080:$CONTAINER_PORT

Публикация Java приложения в личный Nexus

Nexus это хранилище артефактов. Артефакт это ваше приложение, например jar-ник. Чаще всего в Nexus сохраняют библиотеки, чтобы другие разработчики могли их подключить в виде зависимости к своему приложению.

Самым большим и открытым Nexus является Maven Central. Он публичный, то есть любой может взять оттуда зависимость. Но что если вам не нужна публичность. Например, мы хотим сделать библиотеку, которой будут пользоваться только наши коллеги с работы, или ваши только вы и ваша команда. Тогда вам нужен Sonatype Nexus.

Nexus Sonatype позволит вам создать свой приватный, ну либо публичный Nexus с авторизацией. Также его можно использовать, как прокси перед Maven Central.

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

Спонсор поста

Настраиваем settings.xml

Скорее всего у вас есть логин и пароль аккаунта в Nexus. Эти данные нужно указать в файле .m2/settings.xml . Если этого файла нет в папке .m2 создайте его.

   nexus-server nexus-login nexus-password   

Настраиваем приложение

Теперь переходим к pom.xml приложения.

В секцию properties добавляем версии плагинов и URL нексуса.

 . http://ip_you_nexus:nexus_port 2.8.2 1.6.8 . 

Добавляем в pom.xml url на репозитории в нексусе: снепшотный и релизный.

  nexus-server $/repository/maven-releases/  nexus-server $/repository/maven-snapshots/  

Обратите внимание на строки 3 и 7, id репозиториев должен совпадать с id в секции server файла .m2/settings.xml .

Мы заменим maven-deploy-plugin на nexus-staging-maven-plugin . После этого мы сможем деплоить в наш нексус командой mvn deploy .

   org.apache.maven.plugins maven-deploy-plugin $ true   org.sonatype.plugins nexus-staging-maven-plugin $  default-deploy deploy deploy    maven-snapshots $/nexus/ true    

Если вам нужно также сохранять исходники и JavaDoc, то добавьте эти плагины:

 org.apache.maven.plugins maven-source-plugin  attach-sources jar     org.apache.maven.plugins maven-javadoc-plugin 2.9.1 $/bin/javadoc   attach-javadocs jar    

Вот и все, теперь вы можете задеплоить артефакт в нексус обычной Maven командой:

mvn clean deploy

Вы можете настроить автоматическую сборку и доставку в Nexus с помощью Gitlab CI, подробнее об этом я писал в статье: Настройка Gitlab CI/CD для Java приложения ��

Наш Звук

Аренда (прокат), продажа звука и света, комплектов звукового и светового оборудования в Санкт-Петербурге недорого

Главная » Аренда » Полный ассортимент » Профессиональный CD проигрыватель Pioneer CDJ-2000 NEXUS

Профессиональный CD проигрыватель Pioneer CDJ-2000 NEXUS

Опираясь на характеристики и функции своего предшественника DJM-2000, DJM-2000nexus использует подключение к локальной сети ProDJ Link, чтобы обеспечить плавную связь с четырьмя CDJ-плеерами или вертушками и двумя ноутбуками. Новая синхронизация Sync Master позволяет ди-джеям установить мастер BPM для четырех проигрывателей CDJ и управлять ими с помощью микшера, а функция Beat Slice позволяет «нарезать» и располагать треки в режиме реального времени. Эти новые возможности в сочетании с такими функциями, как Quantized Beat Effects, Live Sampler и студийного качества Instant FX обеспечат по-настоящему мощные возможности для создания ремиксов.

Новый флагманский микшер сохраняет популярный 5,8-дюймовый LCD сенсорный экран своего предшественника, чтобы обеспечить множество способов манипулирования музыкой. В дополнение к таким функциям как Sync Master и Live Sampler, ди-джеи могут использовать сенсорную панель для управления тремя инновационными режимами работы — Frequency Mix, расширенный режим Side Chaining Remix и MIDI-режим — для создания ещё более оригинальных треков.

Микшер профессионального уровня DJM-2000nexus разработан специально для клубов. Новый Peak Limiter устраняет искажения и перегрузки, даже при большой громкости, а высоко производительные канальные фейдеры обеспечивают плавное движение и долгий срок службы. Улучшая аудио качество DJM-2000, микшер DJM-2000 nexus может похвастаться более низким джиттером DAC clock на выходе Master Out и A / D конвертером, который присутствует в серии DJM. Кроме того, хромированные платтеры и белая светодиодная подсветка подчеркивает дизайн CDJ-2000nexus.

Основные характеристики DJM-2000nexus:

ProDJ Link обеспечивает мульти-DJ игру и расширенные возможности для производительности
ProDJ Link настройка позволяет подключить по локальной сети до четырех CDJ или вертушек и два ноутбука одновременно. Rekordbox музыкальные файлы, хранящиеся на USB / SD картах могут быть разделены между несколькими проигрывателями, и ди-джеи могут легко переключаться между ними.
Это легкое подключение обеспечивает дополнительные творческие возможности:
Beat Slice: спонтанно сэплирует, «нарезает» треки для создания оригинальных аранжировок — функция Quantize анализирует Rekordbox информацию о треках на подключенных CDJ для автоматической тактовой привязки.
Sync Master: устанавливает желаемый мастер BPM и позицию бита на микшере и синхронизирует до четырех CDJ, что устраняет необходимость устанавки отдельно на каждый канал.
Quantized Beat Effects: запускает DJM-2000nexus популярные эффекты Beat Effects. Quantize функция использует ProDJ Link для получения Rekordbox BPM и бит информации с подключенного CDJ или ноутбука, для автоматической синхронизации всех Beat Effects.
Live sampler: подхватывает сэмплы на лету – с дорожки или микрофонного входа — и загружает в CDJ для создания мгновенного ремикса, скретчей, лупов или воспроизведения.
Пиковый ограничитель устраняет искажения даже при больших громкостях

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

Высоко производительные фейдеры канала

Фейдеры DJM-2000nexus рассчитаны на долгий срок службы в жестких условиях клуба. Два металлических бегунка обеспечивают гладкость и прочность, механизм расположен вдали от открытой лицевой панели и в стороне от пыли и посторонних предметов.

Улучшенное качество звука для клуба

DJM-2000nexus обеспечивает превосходное качество звука, основанное на качестве звука своего предшественника. Встроенная USB звуковая карта может одновременно принимать входные и выходные звуковые сигналы без ухудшения качества звука. DAC на Master Out был обновлен до более низкого джиттера. Выход монитора и 32-битной A / D конвертер самого высокого качества на DJM диапазоне микшера обеспечиваетпревосходное качество звука на всех выходах, а 32-разрядный DSP подавляет цифровой шум.

Большой полноцветный сенсорный дисплей с тремя инновационными режимами работы

DJM-2000nexus сохраняет преимущества предшественника DJM-2000: 5,8-дюймовый большой ЖК мульти-сенсорный экран позволяет ди-джеям видеть и слышать эффекты, сэмплы, master sync информацию и каналы во время воспроизведения — и управлять ими с помощью тактильных команд таких, как Tap и Trace. Ди-джеи могут использовать сенсорную панель для управления тремя инновационных режимами работы:

Frequency Mix режим: семи-полосный кроссфейдер, ди-джей может выбрать частоты в миксе.
Enhanced Side Chain Remix режим: DJM-2000nexus заимствует технологии из новаторских RMX-1000 ремикс станций.
MIDI режим: для управления ПК и ноутбуками с запущенным практически любым DJ программным обеспечением на рынке.
INST FX для интуитивного управления и звука студийного качества

Высокое качество FX — фильтр высоких частот, фильтр низких частот, Jet, Zip, Crush и очень популярный Шум — это мгновенный доступ с помощью специальной кнопки. Есть специальные ручки a Low Pass и High Pass Filter для каждого канала, а каждый эффект может быть доработанс помощью большого вращающегося диска.

Профессиональный дизайн и элегантная отделка

DJM-2000nexus получил несколько косметических усовершенствований. Было применено хромирование для дисков , а также белые светодиоды Beat Effects для всестороннего стильного дизайна.

Другие особенности DJM-2000nexus:

«Инфраструктура как код» в автоматизации сервисов CI/CD

Привет! Меня зовут Игорь Николаев, я пью за любовь работаю в отделе автоматизации процессов разработки Мир Plat.Form в НСПК. В этой статье я поделюсь тем, как наш отдел решал задачу по автоматизации предоставления различных ресурсов для команд разработки. Эта задача свойственна организациям с большим количеством проектов, инфраструктура которых состоит из распределенных и, возможно, слабо связанных сетевых сегментов.

В статье описан PoC (Proof of concept) решения задачи выделения ресурсов в рамках сервисов CI/CD (Continuous Integration & Continuous Delivery) и предоставления привилегий для пользователей этих сервисов.

Описание

Часто в организациях используются сложные и дорогостоящие IDM - класс систем Identity Management (как в рамках лицензирования, так и внедрения и обслуживания) для управления доступами. Нам хотелось совместить процессы запроса и предоставления ресурсов на сервисах CI/CD и предоставления доступов к этим ресурсам. Хотелось получить максимально прозрачное и простое в поддержке и реализации решение, которое обеспечивает следующий функционал:

• Создание и управление сущностями сервисов CI/CD
• Использование удобных для нас инструментов
• Легкая интеграция с уже развернутыми у нас системами
• Простота эксплуатации
• Возможность тиражирования

Про тиражирование стоит сказать подробнее, у нас есть несколько сетевых сегментов с разными сервисами CI/CD, и иногда они имеют минимум сетевой связанности. Система должна с минимальными затратами обслуживать несколько окружений, которые могут отличаться друг от друга.

Что мы выбрали для PoC:

Как подход был выбран IaC (Infrastructure-as-Code) с описанием желаемых состояний в виде yaml файлов.
Python — язык для написания автоматизации (подходящий вариант для прототипа);
Bitbucket — веб-сервис для хостинга проектов и их совместной разработки;
Jenkins — сервис непрерывной интеграции (необходим нам для визуализации выполнения задач).

Как пилотные системы для автоматизации были выбраны:

Active Directory — всем известные службы каталогов (нам понадобятся группы и пользователи);
Bitbucket — часто запрашивают создание проектов, предоставление привилегий;
Nexus 3 OSS (не реклама, нет страницы в Wiki) — корпоративная система хранения артефактов, при появлении проектов создаются персональные репозитории проекта и выдаются привилегии.

Разговор об автоматизации следует начать с описания общей концепции.

В Bitbucket есть две важные сущности: проект(project) и репозиторий (repository), который входит в состав проекта. Для описания доступов в рамках концепта мы решили ограничиться доступами к проекту (более сегментированное предоставление привилегий (на репозиторий) в рамках концепта не потребуется).

У project в Bitbucket есть параметр project key, который понадобится для дальнейших манипуляций, мы взяли его за связующую основу. Именно он и будет являться названием директории в git-репозитории meta. В директории проекта будут размещаться meta-файлы (карты) проекта описанные в формате yaml.

Проектов в Мир Plat.Form много, и у каждого есть своя специфика. Возникает мысль держать в одном месте информацию о группах, инструментах, требуемых проекту, стендах (наборах серверов) и прочего, что имеет отношение к проекту. Для этого отлично подходит git репозиторий.

Какие задачи это решает?

• В первую очередь, мы получаем стандартный интерфейс описания, который создает однотипные сущности сервисов CI/CD.
• В любой момент времени мы можем увидеть реальное описание пользователей и их привилегий в рамках проекта.
• Выполняя автоматизацию по расписанию можно гарантированно получать именно то, что описано в проектных метаданных (защита от «очумелых ручек»).
• Расширяя описание проекта в виде определенной структуры meta-данных, можно автоматизировать другие сущности.

Структура meta репозитория git:

DEV — наименование сетевого сегмента
project1 — ключ проекта в Bitbucket
project1_meta.yaml — карта проекта
examples — директория примера описания

Такая структура позволит описать несколько различных сетевых сегментов, при этом сохраняя гибкую возможность изменений и различий между ними.

Скрипты автоматизации в рамках концепта будут находиться в проекте в отдельных репозиториях (названия не принципиальны):

• ad-core-automation
• bitbucket-core-automation
• nexus-core-automation
• jjb-core

О назначении первых трех репозиториев легко догадаться. Последний репозиторий jjb-core — репозиторий в котором мы будем хранить описание Jenkins Job в виде рецептов для Jenkins Job builder (о нем будет рассказано ниже).

Автоматизация Microsoft AD

Active Directory используется во многих организациях. Большое количество рабочих процессов организаций начинаются именно с него. У нас в Мир Plat.Form все сотрудники имеют учетные записи в AD и включены в различные группы.

За AD отвечает подразделение инфраструктуры. Для наших нужд была выделена техническая учетная запись (ТУЗ), которой делегировано управление одним из Organization unit (OU). Именно в нем с помощью простой автоматизации мы будем создавать группы и наполнять их пользователями.

Часть содержимого project1_meta.yaml, которая отвечает за AD:

--- READY: True # Защита от "дурака", если не True, то автоматизация проигнорирует весь файл TEAM: # Описание состава команды (роли) USER_LOCATION: ldap # local or ldap ROLES: owner: - owner1 developer: - developer1 - developer2 qa: - qa1 - qa2 GLOBAL_PRIVILEGES: &global_privileges # Базовый набор привилегий для каждой роли в команде owner: [read, write, delete] developer: [read, write] qa: [read]

READY — булево значение и позволяет, в случае необходимости, выключить автоматизацию обработки данного мета файла
TEAM — секция, описывающая сущность проекта
ROLES — произвольные названия ролей на проекте, отображающие суть
GLOBAL_PRIVELEGES — секция описывает, какая роль будет обладать какими привилегиями
Пример мета репозитория

В рамках предоставления прав для окружения разработки, чтобы не усложнять пример, остановимся на 3х основных ролях: owner, developer, qa (в целом, количество и наименование ролей является произвольным). Для дальнейшей автоматизации эти роли позволят покрыть большую часть повседневных потребностей (у нас сразу появились роль tech, для ТУЗ, но для примера обойдемся без нее).

В рамках OU проекта будем автоматически, на основании meta-файлов проекта, создавать необходимые SG (Security group) и наполнять их пользователями.

На схеме структура выглядит так:

В AD используем плоскую иерархическую структуру, это позволит ее легко обслуживать, и выглядит она весьма наглядно.

Скрипт автоматизации получился очень простой. Он позволяет отслеживать изменения в составе групп (добавление/удаление пользователей) и создавать OU/SG.

Для запуска потребуется установить зависимости из requirements.txt (ldap3, PyYAML).

Автоматизация Sonatype Nexus3 OSS

Что такое Nexus? Nexus — это менеджер репозиториев, позволяющий обслуживать разные типы и форматы репозиториев через единый интерфейс (Maven, Docker, NPM и другие).

На момент написания статьи версия была OSS 3.25.1-04

Почему именно Nexus?

Есть community версия, которая обладает богатым функционалом, достаточным для выполнения большинства задач, связанных с хранением артефактов и проксирования внешних репозиториев.

Процесс хранения артефактов является важным при проектировании конвейера тестирования и развертывания.

Что потребуется автоматизировать?

Blobstore
Все двоичные файлы, загружаемые через proxy репозитории (мы не предоставляем прямого доступа к интернет репозиториям, используем исключительно прокисрование через nexus), опубликованные в hosted (локальные репозитории) репозитории хранятся в хранилищах Blob-объектов, связанном с репозиторием. В базовом развертывании Nexus, с одним узлом, обычно связаны с локальным каталогом на файловой системе, как правило, а каталоге sonatype-work.
Nexus версии >= 3.19 поддерживает два типа хранилищ File и S3.

Как мы видим, по умолчанию нам уже доступно хранилище default. Из информации выше мы можем понять, что данный blob находится на диске и ему доступен весь объем дискового раздела, на котором находится директория sonatype-work.

Проблематика

В целом, все логично, но есть минимум две проблемы, о которых следует задуматься:

1. В случае, если все репозитории будут привязаны к одному blob, у нас могут появиться проблемы с тем, что хранилище может побиться.
2. Если мы предполагаем, что наш Nexus будет использоваться несколькими командами разработки, то стоит сразу задуматься о том, что в некоторых ситуациях чрезмерная генерация артефактов может забить весь раздел и проблема будет не только у команды, которая генерирует большой объем артефактов, но и у других команд.

Простое решение

Первое, что приходит в голову — это создание отдельных blob stores. Очевидно, это не решает проблему расположения на одном дисковом разделе. Подходящим решением является "нарезать" разделы для каждого проекта. Забегая вперед, это решит еще и вопрос мониторинга и отправки уведомлений ответственным за проект. Удобное решение второго пункта описанных проблем.
По первому пункту наиболее правильным решением является создание отдельных blob store для каждого репозитория.

UI создания Blob stores:

Nexus позволяет настроить Soft quota, штука сомнительная. Она уведомляет о том, что с местом что-то не так, но не производит каких-либо действий. При правильном применении шагов, описанных выше, удается добиться большего функционала (Появляется простой способ отслеживания объема и обращений к диску, а переполнение не создает неприятности "соседям").

В поле path мы можем указать раздел, который примонтирован, например, как nfs.
Что позволяет держать раздел непосредственно на сетевом хранилище. Это может снизить скорость, но дает ряд преимуществ с точки зрения простоты.

Nexus у нас запускается в Docker, для этого используется compose файл. Для подключения новых точек монтирования, простым решением будет добавить в compose файле монтирование родительского каталога точек монтирования.

version: "3" services: nexus3: container_name: nexus3 image: sonatype/nexus3:3.27.0 ports: - 8443:8443 - 50011:50011 # project1-docker-releases - 20012:50012 # project2-docker-releases volumes: - /nexus/sonatyep-work:/nexus-data - /mnt-blobs:/mnt-blobs - /etc/timezione:/etc/timezone - /etc/localtime:/etc/localtime logging: driver: "json-file" options: max-size: "10m" max-file: "10"

Repositories
Nexus позволяет создавать репозитории почти всех распространенных форматов. Если идти в сторону идеального хранения, то целесообразно для каждого проекта создавать минимум release и snapshot репозиторий, хотя идеальный вариант может содержать еще и release-candidat репозиторий. Это позволит настроить удобный механизм чистки репозиториев.

Определенно, release репозиторий должен во многих случаях иметь максимальную глубину хранения, как требование, в релизах не должно оказаться "мусора". Напротив, с репозиториями snapshot мы должны иметь возможность очищать без опасений в любое удобное время и без рисков.

Ко всем форматам репозиториев доступ осуществляется по 80 и/или 443 портам, за исключением docker. Репозиторий Docker, для доступа к нему, должен иметь персональный порт. Это приводит к некоторым сложностям. Каждый раз публикуя новый порт, мы должны добавлять его публикацию в compose файле.

LDAP
Nexus имеет возможность реализации подключения к LDAP и использования его в качестве аутентификации пользователей. В нашем случае мы используем группы пользователей для предоставления прав.

Roles
Для удобства роли создаются под проект, лучше идти от минимума, и для себя мы выбрали три роли для каждого проекта:
qa — обладают правами достаточными для read
developers — read, write
owners — read, write, delete
Группы из AD матчатся в локальные группы Nexus.

API
Начиная с версии Nexus OSS 3.19 появилось весьма удобное API для управления Nexus, это значимое нововведение, которое многие пользователи ждали позволит нам управлять Nexus и приводить его в нужное состояние.

На момент написания статьи API, по большей части, в статусе beta, но не смотря на это, работает без больших проблем и позволяет автоматизировать почти все необходимое.

Часть содержимого project1_meta.yaml, которая отвечает за nexus:

RESURCES: # Ресурсы, обслуживаемые автоматизацией nexus: repository: # Сущности # Maven - name: test-maven-releases locationType: hosted repoType: maven - name: test-maven-proxy locationType: proxy blobStoreName: test remoteUrl: http://test.ru repoType: maven # Docker - name: test-docker-releases locationType: hosted repoType: docker - name: test-docker-proxy locationType: proxy blobStoreName: test-blob remoteUrl: http://test.ru repoType: docker - name: test-docker-group blobStoreName: test-blob locationType: group httpPort: 10555 repoType: docker memberNames: - test-docker-releases - test-docker-proxy # Npm - name: test-npm-proxy locationType: proxy remoteUrl: http://test.ru repoType: npm blob: - name: test-blob path: test-blob privileges: 

def maven_model_hosted(params): model = < 'name': params.get('name'), 'online': params.get('online', True), 'storage': < 'blobStoreName': params.get('blobStoreName', params['name']), 'strictContentTypeValidation': params.get('strictContentTypeValidation', True), 'writePolicy': params.get('writePolicy', 'ALLOW') >, 'cleanup': < 'policyNames': params.get('policyNames', []) >, 'maven': < 'versionPolicy': params.get('versionPolicy', 'MIXED'), 'layoutPolicy': params.get('layoutPolicy', 'PERMISSIVE') >> return model

. bitbucket: name: project1-bitbucket-project # Это не project key! # project_key получается из имени файла description: "Описание проекта в свободной форме" privileges:  

--- - job: # Создаем директорию CORE name: CORE project-type: folder - job: # Создаем поддиректорию ad-core-automation в CORE name: CORE/ad-core-automation project-type: folder # Описание темплэйта - job-template: name: 'CORE/ad-core-automation/-' project-type: pipeline job_description: Упралвение OU и SG для # Defaults GIT_BRANCH: master GIT_CRED_ID: jenkins-ad-integration triggers: - timed: 'H(0-59) * * * *' parameters: - string: name: GIT_BRANCH default: '' description: Git ref (branch/tag/SHA) - string: name: GIT_CRED_IDjenkins default: '' description: Jenkins credentials ID for BitBucket - string: name: META_LOCATION default: 'DEV//_meta.yaml' description: Meta file location if CORE/meta repository dsl: !include-raw-escape: ./ad-core-automation.groovy - project: name: ad-core project_key: - project1 - project2 - project3 jobs: - 'CORE/ad-core-automation/-' 

def meta_location = params.META_LOCATION def git_cred_id = params.GIT_CRED_ID def git_branch = params.GIT_BRANCH pipeline < agent < label 'common-centos' >stages < stage('Clone git repos') < steps < echo 'Clone meta' dir('meta') < git credentialsId: "$", url: 'git@github.com:Mir-Platform/meta-example.git' > echo 'Clone ad-core-automation' dir('auto') < git credentialsId: "$", branch: git_branch, url: 'git@github.com:Mir-Platform/ad-core-automation.git' > > > stage('Install and run') < steps < echo 'Install requirements' withDockerContainer('python:3.8.2-slim') < withEnv(["HOME=$"]) < sh 'pip install --user --upgrade -r auto/requirements.txt' sleep(5) echo 'Run automation' withCredentials([usernamePassword(credentialsId: 'ad_tech', passwordVariable: 'ad_pass', usernameVariable: 'ad_user')]) < dir('auto') < sh "./run.py -u $ad_user -p $ad_pass -f ../meta/$" > > > > > > > >