Возможно, кто-нибудь посоветует решение, а то мне что-то пока в голову ничего не пришло. Ситуация такая. Есть azure pipeline который собирает пару файлов в свою папку "$(Build.ArtifactStagingDirectory)". Мне хочется просто тупо выложить оттуда эти файлы куда-нибудь туда где я мог бы их скачать руками.

Поясню детальней, т.к. вдруг кто-нибудь предложит совсем иное решение. Пайплайн собирает нагетовский пакет + пакет символов к нему (*.snupkg). Я не хочу публиковать их на nuget.org напрямую из пайплайна, тем более там плд линуксовой виртуалкой есть проблемы при работе с PAT. Вот и есть желание просто их собирать, а потом скачивать и публиковать вручную.

hVostt,

Да, я, конечно про него знаю. Но оно просто файлы хранить не может - туда можно только пакеты класть. напр. тот же нагет или нпм. Впрочем, я решил все-таки паблишить прямо из пайплайна. Буду просто ветки develop, release/* и т.п. паблишить в артефакты как превью-версии, а после проверки всего и вся при мерже из release/* в master паблишить релизную версию на nuget.org. В принципе, если все предварительно проверяется, то какая разница откуда пушить - с локальной машины или из пайплайна.

А какая по сути разница? Я по любому руками паблишить это не буду, а какой-нибудь скрипт напишу, а тогда ведь без разницы будет этот скрипт на PowerShell и запускаться руками или это будет azure-pipelines.yml и запускаться тоже руками, когда я буду вливать release/* в master.

А с артефактами тут такая еще проблема. Туда нельзя положить *.snupkg (symbol package) и он в итоге теряется. А nuget.org просит именно его (если ты хочешь для пакета эти отладочные символы поддерживать).

hVostt,

Кстати, в azure-pipelines.yml есть даже специальная разновидность job-а "deploy job" т.е. сами их разработчики совсем херовой идеей это не считают.

Да и еще ведь вообще можно на task поставить "condition: eq(variables['Build.Reason'], 'Manual')" - тогда он вообще будет только совсем явно руками запускаться.

hVostt,

What is Azure Pipelines?

авторAzure Pipelines combines continuous integration (CI) and continuous delivery (CD) to constantly and consistently test and build your code and ship it to any target .

авторUse Azure Pipelines to deploy your code to multiple targets. Targets include container registries, virtual machines, Azure services, or any on-premises or cloud target.

Вот, опять-таки, вы же не руками после сборки и тестов все развертываете, а используете какие-то инструменты. Тут точно так же, только в данном случае это azure pipelines, т.к. он и задуман не только как инструмент для сборки и тестов, а и инструмент для развертывания тоже.

Может быть, но я в случае сборки не конечного продукта, а каких-то библиотек (тот же NuGet) не вижу тут особого криминала. Какая разница, если билд для деплоя ничем от самого крайнего билда для тестов не отличается, так как делается с одного и того же коммита.

Да я целиком за то, чтобы сначала собирать, а потом отдельным запуском уже собранное выкладывать. Но вопрос-то изначальный в том и был - куда собирать-то, чтобы потом это можно было выложить. В артефакты не получается (из-за неподдержки ими *.snupkg), а больше ничего вроде как и нет - заливать сборку на какой-то еще сторонний сервис это отдаёт каким-то геммороем.

Оказалось-таки в ажуре есть ровно то, что надо. Просто там это называется "Universal Package" и меня это с толку сбило.