#devops #artifactory
#devops #artifactory
Вопрос:
Я пытаюсь понять, как использовать Artifactory в довольно сложной настройке сборки. У нас есть несколько сборочных машин, выполняющих многочасовые сборки нескольких компонентов из одной и той же кодовой базы.
Я хочу, чтобы Artifactory рассматривал все артефакты, возникающие в результате одного git-хэша, как одну сборку, даже если они были созданы несколькими машинами сборки. Я также хочу позже запустить тесты для сборки и добавить результаты тестирования к этой сборке. И, в конце концов, продвигайте сборки и загружайте их артефакты.
Мой вопрос в том, как этого можно достичь, используя функцию интеграции сборки в Artifactory?
Я попробовал недавнюю функцию добавления сборки, которая звучит идеально из доступной небольшой документации. Он может создать новую агрегированную сборку, состоящую из нескольких существующих опубликованных сборок. Однако я не могу понять, как использовать агрегированную сборку для чего-либо полезного (например, для загрузки агрегированных артефактов), или я что-то упускаю?
Какова предполагаемая цель функции добавления сборки, если не то, что мне нужно?
Комментарии:
1. Мы планируем улучшить новую агрегированную информационную структуру сборки и разрешить загрузку артефактов всех добавленных сборок. Это планируется внедрить в ближайшем будущем.
2. Мы поддерживаем размещение метаданных для артефактов на Reliza Hub — relizahub.com — если вы не возражаете против другого инструмента. Он имеет возможность связывать сборки и использовать их в различных контекстах CI / CD.
3. Спасибо @EyalBenMoshe У вас есть дорожная карта, показывающая, что вы собираетесь делать с этой функцией? Это было бы очень полезно для нашего выбора платформы.
4. Будет ли проверка relizahub.com слишком. Спасибо!
5. Мы собираемся запустить эту функциональность в течение следующих нескольких недель. Команда «jfrog rt dl» уже принимает параметр —build, который позволяет загружать артефакты по их сборке. Эта опция вскоре позволит загружать артефакты всех агрегированных сборок, на которые ссылается build-info рекурсивно.
Ответ №1:
Функция загрузки из добавленной сборки доступна с JFrog CLI 1.45.0.
Вся новая функциональность прозрачна для пользователя. Чтобы загрузить артефакты сборки, запустите jfrog rt dl --build=<buildName>/<buildNumber> . Если сборка имеет агрегированную сборку, артефакты агрегированной сборки также будут загружены.
Это доступно для всех команд удаленных артефактов JFrog CLI: поиск, загрузка, удаление, перемещение, копирование и т. Д.
Пример использования:
# Create and publish build a/1
jfrog rt upload foo.zip generic-local --build-name a --build-number 1
jfrog rt build-publish a 1
# Create build b/1
jfrog rt upload bar.zip generic-local --build-name b --build-number 1
# Append published build a/1 to b/1
jfrog rt build-append b 1 a 1
# Publish b 1
jfrog rt build-publish b 1
# Download foo.zip and bar.zip
jfrog rt download --build=b/1
Подробнее читайте здесь.
Комментарии:
1. Привет! Хотя это работает, это не очень полезно, поскольку продвижение сборки в настоящее время не продвигает агрегированные сборки. Поэтому, если вы хотите использовать продвижение сборки, вам все равно придется добавить дополнительную логику, чтобы найти все агрегированные сборки и продвигать их отдельно. Есть ли у вас какие-либо планы по поддержке агрегированного продвижения?
2. @arvidr Я не уверен, что понимаю ваш вариант использования. У вас может быть 2 сборки в 2 репозиториях. В настоящее время вы можете продвигать сборку из репозитория A в репозиторий B. Каким в этом случае будет целевой репозиторий артефактов второй сборки?
3. Мой типичный вариант использования следующий: 1. Мы запускаем одну сборку верхнего уровня с определенным Git-хэшем 2. Конструктор верхнего уровня порождает сборщики в Windows, macOS и Linux. Возможно, несколько сборщиков для OS 3. Отдельные разработчики завершают свою работу и загружают артефакты в тот же репозиторий, но с использованием отдельных номеров сборки. 4. Конструктор верхнего уровня добавляет все вложенные сборки в один buildname / buildnumber Это все здорово! Наш QA может использовать сборку верхнего уровня для загрузки всех файлов и т. Д., И мы можем ссылаться на эту сборку и потенциальный выпуск, Используя buildname / buildnumber в качестве уникального идентификатора.
4. Однако мы не можем продвигать сборку верхнего уровня в промежуточный репозиторий, поскольку это не приведет к перемещению каких-либо файлов. Нам нужно продвигать все вспомогательные сборки индивидуально, что требует ручной работы или написания сценариев и как бы ограничивает полезность агрегированных сборок. Я думаю, было бы разумно, если бы агрегированными сборками можно было управлять так же, как и другими сборками, например, в отношении продвижения.