【2022鐵人賽】基本版-建立Pull Request(PR) Pipeline

前一篇重新認識了YAML結構之後,今天我們就來建立前面流程規劃中提到的PR Pipeline吧!

這邊有些項目需要事前準備,就是我們會需要兩個不同的Git Repository,名稱分別是Pipelines與NetApp,因為去年的文章就有建立過Repo,所以這邊就省略建立的內容囉!

PR用的Pipeline會在分支合併之前執行,可以做一些檢查或測試,但是為了不要分散主題,所以這邊我們就只會透過script印出一些內建的資訊,內容並不多也不困難,直接看YAML內容吧!

trigger:
- none

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
  - repository: sources
    type: git
    name: ironman2022/NetApp
    ref: Develop

jobs:
  - job:
    steps:
      - checkout: sources
        clean: true
      - script: |
          echo "PR check process..."
          echo "Build.Reason: $(Build.Reason)"
          echo "Build.Repository.Name: $(Build.Repository.Name)"
          echo "Build.SourceBranch: $(Build.SourceBranch)"
          echo "Build.SourceBranchName: $(Build.SourceBranchName)"
          echo "Build.SourceVersion: $(Build.SourceVersion)"
          echo "System.PullRequest.SourceBranch: $(System.PullRequest.SourceBranch)"
          echo "System.PullRequest.TargetBranch: $(System.PullRequest.TargetBranch)"
          dir $(Build.SourcesDirectory)
        displayName: PR check

從上面的YAML內容可以看到在pool底下我們設定了vmImage,選擇使用最新ubuntu版本的agent,而在resources底下的repositories內,我們定義了一個名為sources的git repository。

「- repository: sources」藍字的sources部份是我們替這個repository resource取的名字,「type: git」紅字的git代表它是一個git repository(type的設定分為git、github、githubenterprise、bitbucket),「name: ironman2022/NetApp」這個name後面的就很有趣了,如果是第一次設定的人可能會因為它是name屬性而搞混,實際上它是用來設定來自「ironman2022」這個Azure DevOps專案裡面的「NetApp」這個Repo,最後的「ref: Develop」則是設定預設要參考哪個分支,這邊設定的是預設使用的分支,通常是手動執行要讓它使用哪一個分支,如果設定了trigger則會依照trigger觸發的分支。

在resources.repositories設定了一個名為sources的git repository之後,在steps底下就可以透過checkout來取得檔案,冒號後面接的名稱就是在resources裡設定的名字,以上面的例子就是「ckeckout: sources」。

建立Pipeline的方式在去年的文章也有說明,這邊同樣就不重複篇幅,只是記得上面提到的,我們建立了兩個不同的Git Repository,名稱分別是Pipelines與NetApp,因此建立Pipeline的YAML檔就存在Pipelines這個Repo,別選錯囉!

Pipeline建好之後,幫它改個名字,因為是針對NetApp的Develop設計的PR Pipeline,所以名稱就用「NetApp Develop PR」吧!

接著我們需要到專案的Repositories設定中去對NetApp Repo設定Policy,選擇Develop分支進入設定Branch policy

新增一個Build Validation

建立完這個Policy之後,我們就可以建立PR來試試看了。這邊我在Local端建立了一個Initialize分支推上去,打算將裡面的檔案合併到Develop分支中。

建立了PR之後就可以看到因為剛剛設定的PR Check Policy而自動觸發的Pipeline正在執行中…

不過剛剛建立的NetApp Develop PR Pipeline因為都還沒執行過,所以會停在等待授權的階段

PR Pipeline執行完之後,如果前面沒有按Set auto-complete的話,要記得回來按Complete

按下Set auto-complete或Complete按鈕之後,會出現四種不同的合併策略,我是比較喜歡用Rebase and fast-forward,如果建立PR的來源分支要保留繼續做別的事的話,第二個選項的「Delete …」要記得取消喔!

最後,看一下我們要Pipeline印出的內容吧!

發佈留言

%d 位部落客按了讚: