這一篇的標題雖然和前面的「基本版-建立CI Pipeline(1)」有點像，但是並不是打算相同的內容再來一次，或是有太多在YAML的部份進階的修改，因為YAML內容的修改部份都已經打散在前幾篇的內容當中了，這一篇是來談談建立新的DevOps Project之後再建立CI Pipeline的時候會碰到的問題。
因為大部份的規則都一樣，加上使用YAML範本，所以前面文章建立的CI Pipeline YAML檔案(放在Pipelines Git Repo)可以直接複製一份到到新的Azure DevOps專案(當然也同樣是叫Pipelines Git Repo，這樣才方便)，只是有些地方要稍微修改，這邊直接貼截圖不貼YAML內容了(因為圖可以框紅線)。
圖中可以看到紅線的地方就是要調整的地方，就是把名稱改成新建立的DevOps專案名稱而已。
建立CI Pipeline的步驟就直接省略了，直接看看建立完成之後會碰到哪些問題吧！
首先是GCP的Service Connection授權問題，如下圖：
就算你直接去按了「Authorize resources」按鈕，會發現也沒有什麼效果，因為真正的動作步驟應該是下面這樣：
因為Service Connection是建立在前面一開始建立Service Connection的專案，也是我們存放YAML範本的專案，所以要到那個專案的Service Connection裡面去Share它，動作如上圖所示。
在Project permissions的區段按下加號，把剛剛建立的新專案加進來，然後就會看到下圖的結果，會使用原本的名稱再加上「-新專案名稱」，這個會同時加在新專案的Service Connection，或是說它只是在這裡是個關聯，在新專案那邊改了名稱之後，這邊的名稱也會變的。
上面紅框的名稱同時也就是在最上面YAML截圖中的imgRegistryService變數的值。
接著再重新執行CI Pipeline，會發現它開始跑了(中間需要授權相關資源的類似截圖請看後面的圖，這邊忘了截圖)，不過跑到BuildImage這個Job的時候卻發現它又失敗了。
這是怎麼回事呢？其實是要跨專案使用YAML範本的Git Repo所發生的授權問題，在Log中也可以發現關鍵字是TF401019這個問題。
要解決這個問題，其實是要在專案設定中把兩個選項關閉，不過一開始進入專案設定的時候會發現它是灰色無法更改的…
專案的設定會是這樣灰色無法更改的狀態，通常就代表它是從更上層繼承下來的設定，所以只要往上追到組織層級的設定就可以看到可以更改的狀態了：
改完組織層級的設定之後，再回到專案設定中去關閉那兩個選項就行了。
再重新執行CI Pipeline，雖然在Checkout範本的那關過了，不過卻發現在Push Docker Image的階段失敗了，因為在GCP的Artifact Registry裡面並沒有建立新專案的存放區，這部份請參考前面的文章來建立。
建立完GCP的Artifact Registry之後再重新執行CI Pipeline，如果是在執行的Log畫面等待，可能會發現怎麼好像不會動？這時候就有可能是有資源需要授權，正等待著去Permit它(只有第一次會這樣)，這在一開始建立CI Pipeline要執行的時候應該就會碰到，只是前面我忘了截圖了。
按下Permit之後應該就可以正常執行完所有的動作，在Log中也可以看得到CloudRun被正確佈署了。