Azure Pipelines многоэтапные задачи для основных шагов - PullRequest
0 голосов
/ 09 ноября 2019

Я пришел из GitLab и его .gitlab-ci.yml, и я экспериментирую с многоступенчатыми конвейерами Azure DevOps, но я совершенно не понимаю, как это работает и какова лучшая стратегия даже после прочтения нескольких статей документации на https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops

Пожалуйста, позвольте мне задать несколько связанных вопросов для базового сценария, который я пробую: скомпилировать, запустить модульные тесты, упаковать пакет nuget для всего решения (он может содержать несколько проектов/ nuGet packages) и опубликуйте пакет в канале nuGet (если ветвь является master, версия выпуска, в противном случае - версия перед выпуском). Это хранилище, из которого я беру код: https://github.com/sasw-diego/sasw-test-support Это сгенерирует только пакет nuGet, но у меня есть другие мультипроектные решения, которые должны генерировать много пакетов nuGet

Это мой azure-pipelines.yml на данный момент:

trigger:
- master
- feature/*

pool:
  vmImage: ubuntu-latest

variables:
  NUGET_FOLDER_NAME: nupkgs
  NUGET_REPOSITORY: https://whatever
  PRERELEASE_SUFFIX: $(Build.BuildId)
  PIPELINE_ARTIFACT_NAME: $(Build.BuildNumber)

stages:
- stage:
  displayName: 'Build'
  jobs:
  - job: 'Build'
    steps:
    - task: NuGetAuthenticate@0
      displayName: 'Authenticate in NuGet feed'
    - script: dotnet restore --no-cache --force
      displayName: 'Restore dependencies'
    - script: dotnet build --configuration Release --no-restore
      displayName: 'Build for Release'
    - script: ls $(System.DefaultWorkingDirectory)
      displayName: 'List content'
    - publish: $(System.DefaultWorkingDirectory)
      artifact: $(PIPELINE_ARTIFACT_NAME)
- stage:
  displayName: 'Automated Tests'
  condition: succeeded()
  jobs:
  - job:
    displayName: 'Unit Tests'
    steps:
    - download: current
      artifact: $(PIPELINE_ARTIFACT_NAME)
    - script: ls -a
      displayName: 'View'
    - script: ls ./test
      displayName: 'View test'
    - script: ls ./test/Sasw.TestSupport.UnitTests
      displayName: 'View folder'
    - script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
      displayName: 'Run unit tests'
- stage:
  displayName: 'NuGet Package'
  condition: succeeded()
  jobs:
  - job:
    displayName: 'Pack Preview Version'
    condition: ne(variables['Build.SourceBranch'], 'refs/heads/master')
    steps:
    - script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME)
      displayName: 'Pack'
  - job:
    displayName: 'Pack Stable Version'
    condition: eq(variables['Build.SourceBranch'], 'refs/heads/master')
    steps:
    - script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME) --version-suffix $(PRERELEASE_SUFFIX) --include-source --include-symbols -p:SymbolPackageFormat=snupkg
      displayName: 'Pack'

  1. Какая "лучшая" стратегия для многоступенчатой? Я вижу, что в конвейерах Azure DevOps есть концепция Stage> Jobs> Task, но все онипохожи на меня. Поэтому я решил разделить процесс на этапы, такие как Build - AutomatedTests - NuGet Package - Publish Как вы можете видеть, это последовательный процесс, в котором каждому этапу нужно что-то из предыдущего. Автоматизированным тестам нужен встроенный код (dll), пакету nuGet также необходим доступ к встроенному коду, публикации нужен доступ к сгенерированному nupkg и т. Д. Я не знаю, нормально ли следовать этой стратегии или лучше иметьодин этап с несколькими заданиями или даже одно задание с несколькими заданиями. Как я уже сказал, я не совсем понимаю, насколько полезно иметь такое количество концепций и как они соответствуют моим потребностям.
  2. Предполагается ли, что многоступенчатые конвейеры Azure заменят старую версию Build и Release как отдельные концепции? Для меня имеет смысл иметь CI / CD в одном месте с многоэтапным подходом и сценариями, чтобы сделать его версионным в репозитории контроля версий. Но я все еще рассматриваю концепцию Release как отдельную концепцию в настоящее время в DevOps Azure. Так что, вероятно, мне следует использовать лазурные конвейеры yml до тех пор, пока пакет не «шагнет», а затем с помощью Release перейдите, возьмите этот nupkg и опубликуйте его в каком-то канале. Не уверен, какая польза будет от этого.
  3. У меня проблемы с выводом этапа в качестве ввода следующего, и, возможно, это из-за того, что я не до конца его понимаю. В приведенном выше сообщении этап сборки завершается успешно , но этап автоматического тестирования завершается с ошибкой при выполнении задания Run Unit Tests с ошибкой No test source files were specified. Я подтвердил, что это происходит, потому что нет сгенерированной папки bin вообще. Это кажется странным, так как я копирую все с предыдущего этапа (а предыдущий этап генерировал папки bin с помощью dll), но затем на следующем этапе, несмотря на возможность загрузки всего, он не может найти тесты.

Это журнал для этапа, который не проходит: https://gist.github.com/sasw-diego/df66eccf71bbfc044a4d72be96268c9a

Было бы очень полезно, если бы кто-то заметил, что мне не хватает, чтобы понять этот процесс. Любая ссылка, чтобы уточнить все эти понятия будет высоко ценится. Ta

PS: Это аналогичный универсальный CI / CD, который у меня был в GitLab для загрузки 1 или нескольких nuGets в канал: https://gist.github.com/sasw-diego/bf46258cb1ad0aa5241e8d1866b53f48

1 Ответ

1 голос
/ 09 ноября 2019
  1. все ваше определение сборки должно быть одной "стадией". Эти Build - AutomatedTests - NuGet Package - Publish не являются этапами, это логические части сборки.
  2. вероятно, когда-нибудь в будущем это может произойти
  3. , потому что вы используете этапы, когда вы не должнык. каждый этап работает на разных агентах. у вас должен быть один этап, и все задачи должны выполняться внутри него.
...