Build Pipeline的YAML結構描述:多個Agent Job

鳴人
·
·
IPFS
·

前一篇的「YAML格式以外的Pipeline傳統編輯器(Classic Editor)」文章內容中看到了一個Pipeline中可以有多個不同的Agent Job,在每一個Agent Job底下再各自加入不同的Task,在前面文章的範例中都只是很單純的加入Task,只在一個Agent的情況下執行Pipeline,這一篇就來看看該如何像Classic editor一樣加入多個不同的Agent Job吧!

底下先來部份回顧前面文章「CI/CD從這裡:設定第一個Pipeline(範本與編輯介面介紹)」內的YAML內容,也就是.NET Desktop的YAML範本:

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

從上面的內容中可以看到在第一層有trigger、pool、variables、steps,而在steps的下一層有多個task,在Pipeline的YAML結構應該是下面的這個樣子:

  • YAML
    • name
    • resources
    • trigger
    • pool
    • variables
    • stages
      • jobs
        • steps
          • script/bash/pwsh/task …

扣除掉前面幾個只會設定一個的項目,範例結構會像這樣:

  • stages
    • 階段A(stage)
      • jobs
        • 作業1(job)
          • steps
            • 步驟1(task)
            • 步驟2(script)
            • 步驟3(pwsh)
        • 作業2(job)
    • 階段B(stage)
    • 階段C(stage)

所以在上面的YAML範例內容中,其實是省略了上層的許多結構描述,這部份在官方的文件頁面上有提到,如果只有單一階段(stage),可以省略關鍵字stages並且直接使用jobs開始。如果只有單一階段(stage)和單一作業(job),可以省略stages和jobs關鍵字,直接使用steps開始。所以在範本的YAML中才會看到只有steps開始定義底下的task的情況。

所以前一篇的「YAML格式以外的Pipeline傳統編輯器(Classic Editor)」文章內容中看到了一個Pipeline中可以有多個不同的Agent Job,實際上在YAML格式的內容中就只是在jobs底下定義多個不同的job,在job底下再放入steps底下的內容即可,下面我以前面文章「CI/CD從這裡:編譯專案與上傳成品」內容中的YAML稍作修改,steps中使用相同的內容,多增加一個job,YAML如下:

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
- none

pool:
  vmImage: ubuntu-latest

jobs:
  - job:
    displayName: Job1
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: 'ConsoleApp/*.csproj'
        arguments: '-o $(Build.BinariesDirectory)'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.BinariesDirectory)'
        includeRootFolder: true
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/Job1-$(Build.BuildId).zip'
        replaceExistingArchive: true
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'BuildOutputFiles'
        publishLocation: 'Container'

  - job:
    displayName: Job2
    pool:
      vmImage: windows-latest
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: 'ConsoleApp/*.csproj'
        arguments: '-o $(Build.BinariesDirectory)'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.BinariesDirectory)'
        includeRootFolder: true
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/Job2-$(Build.BuildId).zip'
        replaceExistingArchive: true
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'BuildOutputFiles'
        publishLocation: 'Container'

從上面的YAML內容可以看到有兩個不同的Job,顯示的名稱分別是Job1、Job2,Job底下的steps幾乎都是相同的內容(複製的),只有在壓縮檔案的名稱內多了Job1、Job2的前綴字來分別,但是在Job1的displayName底下並沒有額外的設定,在Job2的displayName底下卻另外設定了pool的內容,指定使用Windows的vmImage。也就是說,Job1使用最上層定義的Linux的vmImage(ubuntu),Job2則是自行另外設定,改用Windows的vmImage。

實際執行的資訊頁如下,可以看到最下面有兩個不同的Job:

點擊任何一個Job都可以進入執行的Log頁面,可以看到下面兩個不同Job的Agent是來自不同的OS(Linux/Windows):

執行之後上傳的成品檔案也如預期以不同的Job名稱為開頭命名:

不同的Job除了可以定義不同的pool之外,也可以定義不同的variables等其它不同的設定,如果需要更多詳細的YAML結構描述內容的定義資訊,可以直接看官方的文件(中文/英文)。

原文連結泰克哪裡去

CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!