上週五，按照慣例Gitlab官方正式釋出了一個新的月度版本13.8。該版本對管道編輯、部署儀表盤等有了很大的改進，還推出了50多項的功能和亮點。請隨蟲蟲一起學習嚐鮮。如果想升級版本，請檢視本文最後的"升級更新"部分。

概述

本次釋出主要加強了對CI/CD方面的易用性，提高管道、部署等的上手難度。

GitLab CI/CD的定義功能一直是透過.gitlab-ci.yml配置檔案。將管道配置為程式碼意味著可以使用與應用程式程式碼相同的介面對管道進行版本控制和協作。但是，所有這些功能和靈活性都帶有相當大的複雜性。。

在新版本中推出了，新的一個功能Pipeline Editor，一個專為CI/CD設計的編輯器，它具有一些增強的功能，例如內建的linting和配置驗證。在提交修改之前，管道視覺化編輯器就能顯示管道的變化。

從GitLab 13.8開始，可以在CI/CD分析中找到部署頻率圖表。這只是GitLab中第一個DORA 4指標。

這些功能讓新使用者可以快速上手GitLab CI/CD，並使經驗豐富的高階使用者更加高效。

GitLab 13.8中主要功能改進管道編輯器

GitLab CI/CD提供了靈活的選項，用來支援各種高階管道用例。管道語法可能很冗長，有時甚至很複雜，特別是對於那些剛接觸GitLab CI/CD的人而言。在新版本中，引入了一個全新的管道編輯器來解決這個難題。

管道編輯器將使新手和高階使用者都更容易配置CI配置。管道編輯器是一個單一解決方案，可將所有現有CI創作功能（以及將來的功能）組合在一個位置。管道編輯器是配置管道時的最佳選擇。

除了編輯經驗外，它還具有其他功能，可幫助編寫管道，而無需額外的手動步驟。CI驗證會持續檢查管道配置，併為提供管道配置有效的指示符。新的Pipeline Visualizer提供管道配置的圖形表示。Lint tab驗證管道語法並提供有關每個作業的詳細資訊。

管道編輯器CI lint工具

CI lint工具可驗證管道的語法，並提供有關每個作業的一些詳細資訊。此前，CI lint位於作業頁面上，不好找到和訪問。在新版本中，該工具已包含在新管道編輯器中。藉助此改進，可以在編輯配置時輕鬆使用CI lint，並在提交更改之前快速驗證語法是否符合要求。

管道編輯器CI/CD配置驗證

以前，要驗證CI/CD配置，必須導航到CI lint頁面或提交更改並查詢任何錯誤。在新版本中，在管道編輯器本身中添加了驗證。會在寫入.gitlab-ci.yml檔案之前連續檢查管道配置，併為提供配置有效的指示。這樣可以節省使用者時間和精力，把工作中心放到最佳化管道上。

管道配置視覺化

作為開發人員，可能很難理解複雜的CI配置，尤其是在嘗試預測管道的行為時尤其如此。如果沒有視覺幫助，就很難對所有工作之間的關係有個感性認識，很難理解它們之間的相互聯絡。在新版本中，透過管道視覺化，使用者現在可以看到.gitlab-ci.yml配置的圖形表示，以更好地理解和預測管道的效能。

部署頻率圖（ULTIMATE）

知道和監視部署頻率是組織採用DevOps的起點。在專案級別引入部署頻率圖表，可以方便使用者和開發團隊隨時間監視部署效率，發現瓶頸，必要時進行改進。

單擊並拖動多行合併請求註釋

對單行進行註釋非常適合簡單的程式碼審查反饋，但註釋通常會涉及多行。例如，邏輯塊的一部分，程式碼段落或整個功能。

直接從合併請求視窗小部件下載工件

在新版本中，增加了直接從MR小部件下載構建構件的功能。這對於移動開發特別有用。例如，使用者要測試在物理裝置或模擬器上建立的特定內部版本的Android程式包。現在，可以直接從合併請求視窗小部件訪問這些工件，而不必查詢隱藏在管道檢視中的工件。

重複失敗的測試計數器

當檢視合併請求的管道執行結果時，可能會有測試失敗，無法進一步調查。通常很難驗證測試失敗是否準確並且需要修復，或者僅僅是一個可以忽略的不穩定測試。重複失敗測試計數器的第一個最小可行更改將為提供測試摘要合併請求小部件上先前管道中測試失敗的頻率的計數。

部署板開放給Core使用者

部署板提供了Kubernetes上執行的每個CI環境的當前執行狀況和狀態的合併檢視，顯示了部署中Pod的狀態。開發人員和其他團隊成員可以在已經使用的工作流程中逐個窗格地檢視釋出的進度和狀態，而無需訪問Kubernetes。

GitLab承諾將18種功能遷移到CE Core產品中。在該版本的GitLab中，完成了將Deploy Boards遷移到Core的工作。

合併請求的Rebase快速操作

Rebase是一個Git命令，用於在新提交之上重新應用提交。實際上，這意味著在最新版本的目標分支（例如main）之上從功能分支重新應用提交。這樣，可以使功能分支保持最新狀態並解決任何衝突，而無需使用合併提交，從而可以簡化線性Git歷史記錄。

GitLab 13.8帶來了在合併請求中執行rebase快速操作的功能，使使用者可以快速呼叫git rebase。

Gitaly群集的分散式讀取（PREMIUM及以上）

使用者希望在高度可用的Gitaly群集中獲得儘可能高的容錯級別。新版本引入了Gitaly Clusters的分散式讀取。這樣Gitaly不再總是從主節點讀取資料，而是自動將讀取請求分配給叢集中的任何最新節點。分配請求使使用者可以訪問群集中配置的所有計算資源，從而最大限度地提高效能和價值主張。使用者還希望防止同一節點上的嘈雜鄰居儲存庫導致效能下降。這個問題對於大型繁忙的monorepos尤為重要，因為那裡有成千上萬的工程師和CI管道同時訪問同一個Git儲存庫。透過水平分佈讀取請求，Gitaly群集可提高群集中所有儲存庫的效能。

GitLab Pages現在在Kubernetes部署的GitLab中可用

GitLab Pages是內建在GitLab中的一種流行的靜態站點託管服務，新版中可用於在Kubernetes上執行的GitLab例項。與Omnibus部署相比，Pages是最後剩下的功能差距之一。

新版本中支援自定義域，但是訪問控制將在將來的版本中提供。

將板的範圍調整為當前迭代（STARTER及以上）

許多團隊使用董事會來管理迭代期間的問題。在13.6中，在特定的Iteration中增加了對板上過濾問題的支援，但是記住每次上板時都要應用該過濾器是很麻煩的。

在新版本中，增加了將板的作用域擴充套件到當前活動迭代的功能。

組成員webhook（編輯，刪除）（PREMIUM及以上）

在GitLab 13.7中，引入了一個Webhook，當一個新成員被新增到組中時被觸發。在GitLab 13.8中，如果使用者的訪問級別已更改，使用者訪問的到期日期已更新或使用者已從組中刪除，則也會觸發組成員事件webhook。透過新增這些事件，可以使用組成員事件webhook來知道對組成員所做的所有更改，而無需依賴API呼叫。

在CI包含部分中支援預定義變數

受監管的客戶依靠GitLab的CI/CD功能來定義和自動化其安全性和合規性工作以及將變更部署到敏感環境的流程。確保編寫程式碼的團隊與部署該程式碼的團隊之間保持職責分離，並且這些作業始終在敏感環境中執行。

在13.8中，現在可以在檔案的部分中使用預定義的專案變數include:.gitlab-ci.yml。此項更改是更大解決方案的一部分，可為GitLab CI/CD管道帶來更好的職責分離。

以自動完成方式顯示所有可用的快速操作

當輸入/描述或註釋欄位時，所有可用的快速操作現在都顯示在可滾動列表中。快速行動是一種有效地更新有關問題，合併請求或Epic資料的好方法，一小小的改進有助於在使用它們的上下文中更容易發現它們。

在迭代報告中按標籤對問題進行分組（STARTER及以上）

現在，可以按標籤在迭代報告中對問題進行分組。這為團隊提供了一種檢視迭代過程中進度的方法，該過程按標籤經常代表的多個維度進行細分。

在專案上禁用運維功能

GitLab提供了多種工具來幫助監視和操作應用程式，但並非GitLab中的所有專案都是Web應用程式。例如，如果正在處理NPM軟體包，託管配置檔案或使用僅Wiki專案，則可能會發現專案不需要操作功能。

在GitLab 13.8中，可以逐個專案禁用"運維"功能，這將刪除對功能的訪問並在左側邊欄中隱藏選單項。可以在"設定">"常規"下的"可見性，專案功能，許可權"部分下找到新配置。以這種方式配置專案可確保只有使用的功能以及專案支援的功能才可用，並且在GitLab介面中可見。

管道規則的支援變數

以前，rules關鍵字的範圍是有限的，只能確定是否應將作業包括在管道中或從管道中排除。在此版本中，可以決定是否滿足某些條件，並隨後覆蓋作業中的變數，從而為配置管道提供了更大的靈活性。

組或子組安裝NuGet軟體包

可以使用專案的程式包登錄檔來發布和安裝NuGet程式包。只需使用NuGet CLI，Visual Studio或.NET CLI將專案新增為源即可。例如，使用NuGet CLI，可以執行：

nuget source Add -Name <source_name> -Source "gitlab /api/v4/projects/<your_project_id>/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

如果專案數量很少，則效果很好。但是，如果一個組中嵌套了多個專案，則可能會很快發現自己添加了數十甚至數百個不同的資源。對於擁有許多團隊的大型組織，團隊通常會將軟體包與原始碼和管道一起釋出到其專案的Package Registry。但是，還需要能夠輕鬆安裝組織中其他專案的依賴關係。

以從小組中安裝軟體包，這樣不必記住哪個軟體包位於哪個專案中。只需將組新增為NuGet軟體包的源即可，可以安裝該組的任何軟體包。

nuget source Add -Name <source_name> -Source " gitlab /api/v4/projects/<your_group_id>/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

改進了管道狀態電子郵件主題行

當管道成功，失敗或修復時，GitLab會發送電子郵件通知。在以前的版本中，這些電子郵件看起來很相似。這使得很難在不閱讀電子郵件正文的情況下告訴管道狀態。此版本更新了這些電子郵件通知的主題行，因此可以快速確定管道狀態。

透過UI管理Terraform狀態檔案

使用Terraform管理基礎結構時，可以建立多個狀態檔案，例如每個分支的狀態檔案。要除錯問題，需要概述專案中附加的狀態檔案，以及可以對每個狀態檔案執行的各種操作。在早期版本的GitLab中，管理Terraform狀態檔案需要用於執行諸如釋放狀態鎖之類的任務的API。新版中引入一個UI來列出現有狀態檔案。它使專案維護人員可以鎖定或解鎖狀態檔案，刪除狀態JSON或完全刪除狀態檔案。

比較儲存庫並驗證它們是否相同

透過校驗每個儲存庫的所有引用，可以將一個Git儲存庫與另一個儲存庫進行比較。如果兩個儲存庫都具有相同的引用，並且兩個儲存庫都通過了完整性檢查，那麼可以確信兩個儲存庫是相同的。例如，這可用於將儲存庫的備份與源儲存庫進行比較。

新增加的gitlab:git:checksum_projects rake任務可以讓系統管理員可以按ID選擇專案的子集或遍歷所有專案，並輸出可以與同一專案的副本進行比較的Git引用的校驗和。

對Alpha中PostgreSQL高可用性的GEO（PREMIUM及以上）

Patroni是PostgreSQL高可用性的解決方案，它還允許在GEO輔助資料庫上配置高可用性PostgreSQL備用群集。當將輔助節點用作災難恢復策略的一部分時，此配置很重要，因為它允許系統管理員映象主節點和輔助節點上的資料庫節點數。這意味著在故障轉移之後，無需調配其他資料庫節點即可恢復高可用性。

現在，Geo使用Patroni為高可用性PostgreSQL配置提供了alpha級支援。Gitlab已經將Patroni升級到2.0.1，添加了故障轉移文件，並修復了許多錯誤。

改進了高階搜尋中的檔案搜尋（STARTER及以上）

在高階搜尋中，搜尋檔案是最常見的用例。在此版本之前，搜尋檔案通常需要一些特定的語法，而且不是很直觀。

在GitLab 13.8中，高階搜尋現在支援全路徑搜尋，檔案語法搜尋也更加靈活。

預設單節點例項將升級到PostgreSQL 12

在GitLab 14.0中，計劃要求PostgreSQL 12。PostgreSQL 12提供了顯著的索引編制和分割槽優勢，並提高了效能。

為了準備，使用Omnigres打包的Postgres版本的單節點例項現在將預設自動升級到版本12。如果願意，可以設定不自動升級。

在使用Patroni進行升級之前，多節點例項以及所有Geo輔助資料庫都需要從repmgr切換到Patroni。然後可以更新GEO輔助資料庫並重新同步。

忙狀態指示燈

透過狀態更新，使用者當前可以與他們的團隊共享個性化狀態訊息和表情符號。透過將自己標記為忙，其他夥伴可以輕鬆地看到何時無法進行程式碼審查和其他任務。在整個GitLab使用者介面中，"忙碌"狀態將顯示在姓名旁邊。

在例項之間直接遷移組

一種更快，更輕鬆地遷移GitLab組的方法正在開發中。組遷移是一項新功能，可讓直接將GitLab組從一個例項複製到另一個例項，而無需匯出和匯入任何檔案。在該版本中，僅遷移具有基本欄位的Group物件。後續計劃會增加越來越多的欄位和相關物件，直到以這種易於使用的方式遷移組中的所有相關資料。

將需求匯出到CSV檔案（ULTIMATE）

完成開發並驗證產品滿足所有要求後，可能需要匯出要求狀態以允許納入更高級別的要求可追溯性分析中。透過引入需求匯出功能，現在可以做到這一點。只需啟動需求匯出，就會以.CSV格式自動傳送。

審閱者的批准規則資訊（STARTER及以上）

在努力使合併請求經過稽核，批准並最終合併時，選擇合適的人員來執行這些任務很重要。要求無法提供批准的人員進行稽核，可能會減緩釋出的過程。

從GitLab 13.8起，在為合併請求選擇審閱者時，可以看到在審閱者名稱的正下方顯示了使用者匹配的批准規則。

連結源合併請求以進行壓縮和合並提交

在GitLab中檢視提交時，包含提交的合併請求被連結。當嘗試查詢更改的業務和技術環境時，查詢添加了提交的合併請求非常有用。

如果使用壓縮或合併提交，則先前不會包含合併請求資訊。在GitLab 13.8中，包括所有提交型別的合併請求連結，從而確保使用者可以找到引入更改的位置。

快速編輯Wiki的側邊欄

_sidebar在Wiki中建立一個名為Markdown的檔案將使用該檔案的內容為專案生成自定義邊欄導航選單。但是，編輯該檔案非常棘手，因為在介面中無處可再次開啟_sidebar。

為Jupyter Notebook使用豐富的輸出

Jupyter Notebook是包含實時程式碼，方程式，視覺化效果和敘述文字的文件。它們被廣泛用於資料清理和轉換，數值模擬，統計建模，資料視覺化，機器學習等。它們能夠使用"豐富的輸出"來顯示物件的渲染表示形式，例如HTML，JPEG，SVG或LaTeX檔案。以前，在Jupyter中開啟Notebook是讀取具有豐富輸出的唯一方法。

GitLab 13.8中，預設情況下將顯示Jupyter筆記本內容的豐富輸出。這是預覽檔案更改以及使用Jupyter Notebook而無需離開GitLab的絕佳方法。

使用退出程式碼控制作業狀態

可以使用allow_failure關鍵字來防止失敗的作業導致整個管道失敗。之前allow_failure僅接受true或false布林值，在新版本中進行了改進，因此現在可以使用allow_failure關鍵字查詢特定的指令碼退出程式碼。這提供了更大的靈活性和對管道的控制，從而防止了基於退出程式碼的故障。

專案配置以控制最新工件的儲存

從最新成功的工作中保留最新工件是一個有用的預設行為，但也會導致大量的儲存使用。如果有生成大量工件的管道，這可能會導致磁碟空間使用量意外增加。為了改善儲存消耗管理，新版本中可以在設定中對任何專案禁用此行為。

使用分支管道和MR管道而不重複

以前，不能預先為分支機構執行管道，然後在建立MR時切換到合併請求管道。因此，在某些配置下，如果分支上的合併請求已開啟，則推送到分支可能會導致重複的管道：分支上的一個管道，而另一個用於合併請求的管道。現在，可以$CI_OPEN_MERGE_REQUESTS在CI配置中使用新的預定義環境變數，以在正確的時間從分支管道切換到MR管道，並防止出現冗餘管道。

GitLab Terraform Provider 3.4更新

如果使用Terraform設定GitLab， GitLab釋出了Terraform Provider的3.4.0版本。在過去的幾個月中，除了許多較小的增強功能和一些錯誤修復之外，還提供了專案映象，組共享，專案批准規則和例項級CI變數的支援。

指標圖直接上傳到事件（PREMIUM及以上）

在故障處理過程中處理事件需要響應者跨多種工具進行協調以評估不同的資料來源。收集和評估指標，日誌和跟蹤，並與響應團隊共享這些指標既耗時又充滿挑戰。透過在事件的新"指標"選項卡中為這些螢幕截圖提供拖放上傳，簡化了此工作流程。彙總並集中放置所有指標的螢幕快照，以便團隊可以快速訪問和參考重要圖表。

在"高階搜尋"中更快地搜尋問題（STARTER及以上）

高階搜尋可以從小型個人例項一直擴充套件。但是，在某些大的例項上，隨著索引大小的增加以及需要檢查的許可權數量的增加，搜尋速度可能會降低。

在GitLab 13.8中，為問題分割了自己的索引，從而使大型例項的"高階搜尋"更快。還簡化了許可權檢查的方法，從而進一步提高了效能。

該更新將自動應用，而無需進行手動重新索引。過程不到2個小時，但是在完成對新內容的索引編制時會有所延遲。

GitLab Helm chart改進

GitLab Pages現在可用於Kubernetes部署

Praefect現在支援多個虛擬儲存。

registry版本已更新至2.13.1-gitlab

Gitlab Runner 13.8

一同還發布了GitLab Runner 13.8。GitLab Runner是一種輕量級，高度可擴充套件的代理，可執行構建作業並將結果傳送回GitLab例項。GitLab Runner與GitLab CI/CD結合使用，GitLab CI/CD是GitLab附帶的開源持續整合服務。GitLab Runner 13.8新功能和改進有：

支援Windows Docker執行器的命名管道。

修復 使用IRSA EKS 1.18上的快取上載。

修復針對Docker和Kubernetes執行程式失敗的作業的快取推送

修復Kubernetes執行器上的Azure快取不起作用。

修復FastZip以支援非root使用者的工件。

新增一個patroni_role，可以輕鬆地為擴充套件的GitLab部署配置Patroni節點。

新增回退到postgresql[X]設定，用於更多的patroni設定。

registry元件已更新至2.13.1-gitlab，grafana從7.3.6patroni到2.0.1的版本。

現在可以配置儲存加密憑證的路徑。

GitLab 13.8包括Mattermost 5.30（一種開源的Slack替代產品），其最新版本包括對Matterpoll外掛的改進，PostgreSQL v9.x的棄用等。

安全和合規性審計程式碼所有者的可選部分（PREMIUM及以上）

程式碼所有者部分允許多個團隊在同一檔案中獨立配置自己的程式碼所有者。透過幫助作者從正確的審閱者那裡獲得反饋，當多個團隊負責程式碼的公共部分時，這將有所幫助。但是，當需要程式碼所有者的批准時，這適用於所有部分，這意味著所有團隊都需要批准，這可以阻止合併後的更改。

GitLab 13.8引入了在CODEOWNERS檔案中指定可選部分的功能。只需在節名稱前加上^字元，該節將被視為可選。這樣透過合併請求進行的相關更改將不需要指定所有者的批准。透過可選部分，可以繼續為程式碼的各個部分指定負責方，同時為專案的某些部分提供更為寬鬆的策略，該策略可能會經常更新但不需要嚴格的審查。

限速空轉模式和繞過機制

設定應用程式的速率限制，以允許來自受信任源的請求同時阻止惡意流量，這可能是一個挑戰。新版中加入一些改進，以使正確設定速率限制變得更加容易。首先，可以使用新的空執行模式測試速率限制設定，該模式將對照每個速率限制檢查請求並記錄結果，而不會實際阻止客戶端。這樣，可以在生產中啟用請求速率設定之前對其進行微調。

其次，還可以配置特定的請求，可以更好地支援受信任的服務。

最後，可以配置特定使用者以繞過速率限制器。這使可以更好地支援可信任的使用者訪問GitLab例項。

為Docker執行器配置多個映象拉取策略

當CI作業從容器登錄檔中檢索容器映象時，丟失的網路連線可能會導致數小時的開發時間損失，並對時間敏感的產品部署產生負面影響。為了解決該彈性問題，GitLab Runner Docker執行程式現在支援對pull_policy配置使用多個值，該值在GitLab Runnerconfig.toml檔案中定義。可以使用這些值或堆疊的映象拉取策略來配置拉取策略的組合，並減輕由於失去連線而造成的影響。例如，如果配置pull_policy =["always", "if-not-present"]，則拉策略將always拉取映象。但是，如果目標容器登錄檔不可用，則GitLab Runner Docker執行程式將回退並使用if-not-present 策略，這意味著將在該管道作業中使用映象的本地副本。

按需DAST掃描器配置檔案中的主動掃描模式（ULTIMATE）

與新的站點驗證功能結合使用時，現在可以在按需DAST掃描器配置檔案中配置活動DAST掃描。驗證站點的所有權後，可以配置活動掃描器對該站點掃描。這些掃描包括對該站點的實際，破壞性的惡意攻擊。建議使用者僅在不關心資料丟失的不包含生產資料的登臺和測試站點上使用主動掃描。

改進了SAST嚴重性資料以解決JavaScript漏洞

安全掃描分析儀可以進行GitLab靜態應用程式安全測試，並將識別漏洞的嚴重性資料。新版中更新了JavaScript分析器ESLint，以增加對嚴重性和CWE資料的支援。該資料將有助於增加安全批准規則的可用性和準確性，因為更少的漏洞將報告"嚴重"。此外，此資料顯示在漏洞詳細資訊頁面上，該頁面提供了更多資訊以及指向有關漏洞的相關資訊的連結，從而使開發人員更容易理解和修復問題。

API Fuzz測試結果顯示在安全儀表板中（ULTIMATE）

在新版本中，API Fuzz測試結果會顯示在安全性儀表板中，安全掃描程式將在所有其他位置顯示其結果。可以對API模糊測試結果進行分類，為它們建立問題，並像與其他掃描器一樣與團隊合作。

這些結果都會從"測試"選項卡到安全儀表盤中，以便可以與其他安全掃描程式整合在一起。

.gitlab-ci.yml模板中新增DAST.latest（ULTIMATE）

GitLab的DAST始終只有一個模板，該模板未進行版本控制，並在需要更改時進行更新。對於模板更新後測試中斷的使用者，這已證明是困難的。從GitLab 13.8開始，新引入.latest模板的版本。該模板包括主要版本之間進行的所有模板更改，包括重大更改。這向用戶發出警告，即將發生更改，並使能夠在被迫切換之前自行測試更改。

重大更改被引入下一主要GitLab版本的穩定模板中。對於不間斷的更改，可以將它們放在最新版本的幾個版本中之後，放入穩定的模板中。將更改合併到穩定模板中的速度取決於許多因素，並且在使用者測試最新模板中的更改時會考慮到使用者的反饋。

按需掃描的站點驗證（ULTIMATE）

從GitLab 13.8開始，使用者可以驗證自己是否擁有或有權作為站點配置檔案新增域。透過將帶有專案和站點特定字串的文字檔案新增到其站點，使用者可以驗證域的所有權。驗證過程將釋放對站點執行活動DAST掃描的能力。由於主動DAST掃描包括針對站點的實際攻擊，因此站點驗證可確保使用者不會意外對可能造成資料丟失或損壞的站點進行主動掃描。因此，任何使用未經驗證的域的站點配置檔案都只能使用使用被動掃描模式的掃描器配置檔案。

效能改進

在每個版本中，致力於提高每個GitLab例項的速度。在GitLab 13.8中，在問題，專案，里程碑等方面提高效能，其中一些改進包括：

在Container Registry索引頁面中減少LCP。

將GraphQL用於漏洞狀態下拉選單。

N+1使用GraphQL解決帶有載入組問題的查詢。

啟用QueryCache了LoadBalancing。

audit_events用分割槽副本交換基本表。

Bug修復

GitLab 13.8中一些值得注意的錯誤修復是：

修復容器掃描不再報告分析器的版本。

修復漏洞報告中"管道安全性"選項卡上的長標題未對齊。

內聯程式碼覆蓋率未在cobertura報告中載入自閉合源標籤。

編輯看板後，應繼續進行分組選擇。

使用GitLab Geo和可識別位置的Git URL時出現LFS問題。

修復管道間歇性lints失敗報錯的故障。

DAST_AUTH_EXCLUDE_URLS－＞DAST_EXCLUDE_URLS。AUTH_EXCLUDE_URLS－＞DAST_EXCLUDE_URLS。AUTH_USERNAME－＞DAST_USERNAME。AUTH_PASSWORD－＞DAST_PASSWORD。AUTH_USERNAME_FIELD－＞DAST_USERNAME_FIELD。AUTH_PASSWORD_FIELD－＞DAST_PASSWORD_FIELD。DAST_ZAP_USE_AJAX_SPIDER－＞DAST_USE_AJAX_SPIDER

DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED將被刪除，該功能已被刪除。

容器登錄檔日誌格式化程式

變更日期：2021年1月22日

目前，GitLab支援：

應用程式日誌的文字，JSON和logstash日誌格式。

用於訪問日誌的文字，JSON和組合日誌格式。

容器登錄檔當前支援只能用於電子郵件通知的日誌記錄Hook。現在，基於日誌條目的警報通常由單獨的工具處理。

當前為Redis連線池公開的一些配置設定與基礎Redis客戶端繫結，並且在替代庫中沒有等效設定。改進Redis整合（例如增加對Sentinel的支援）後，決定開始著手嘗試以功能更豐富的替代方法來替換當前的Redis客戶端依賴項，從而更好地為其提供支援。為此，需要替換繫結到當前客戶端庫的當前Redis池配置設定：

增加redis.pool.size（最大連線數），redis.pool.minidle（最小空閒連線數）和redis.pool.maxlifetime（可以重用連線的最大時間）設定。

停止Bugsnag和NewRelic的Container Registry支援

變更日期：2021年1月22日

停止對TLS 1.0和1.1格式的Container Registry支援

變更日期：2021年1月22日

出於安全性考慮，由於GitLab不再支援TLS 1.0和TLS 1.1。將對當前支援1.0（預設），1.1、1.2和1.3的GitLab容器登錄檔進行同樣的操作。

Gitaly停止對TLS 1.0和1.1的支援

變更日期：2021年1月22日

Gitaly將配置為至少對所有客戶端和伺服器端連線使用TLS 1.2。

停止對Docker登錄檔API v1的支援

變更日期：2021年1月22日

透過完成以下步驟，GitLab上的v1登錄檔API的現有使用者可以移至v2登錄檔API：

將的Docker Engine更新到17.12或更高版本，以便與v2登錄檔API相容。

如果在GitLab中具有v1格式的內容，則可以使用較新的Docker客戶端（比1.12更新的版本）將其移至v2格式，以重建映象並將其推送到GitLab。

Git預設分支名稱更改

變更日期：2021年6月22日

Git儲存庫都有一個初始分支。這是建立新儲存庫時自動建立的第一個分支。預設情況下，此初始分支名為master。Git版本2.31.0（計劃於2021年3月15日釋出）會將Git中的預設分支名稱從master更改為main。為了與Git專案和更廣泛的社群協調， GitLab 14.0開始的自建例項上新專案的預設分支名稱。該變更不會影響現有專案。

GitLab Runner安裝程式忽略skel目錄

變更日期：2021年6月22日

在GitLab Runner 14.0中，skel預設情況下，安裝過程將在建立使用者主目錄時忽略該目錄。

Windows Runner的預設shell改為pwsh

變更日期：2021年6月22日

在GitLab Runner 13.2中，PowerShell Core支援已新增到Shell執行程式中。在14.0中，pwsh它將是新註冊的Windows執行程式的預設外殼程式。Windows CMD仍可作為Windows執行程式的外殼程式選項使用。

停止PostgreSQL 11支援

變更日期：2021年6月22日

PostgreSQL 12將是GitLab 14.0中最低要求的版本。它為索引編制，分割槽和一般效能優勢提供了重大改進。

從GitLab 13.7開始，所有新安裝的預設版本均為12。在GitLab 13.8中，單節點例項也將自動升級。如果還沒有準備好升級，則可以選擇退出自動升級。

在使用Patroni進行升級之前，多節點資料庫例項將需要從repmgr切換到Patroni。然後可以更新GEO輔助資料庫並重新同步。

作為遷移到GitLab中所有安全掃描器的通用報告格式的一部分，DAST正在對DAST JSON報告進行更改。某些舊版欄位在13.8中已棄用，並將在14.0中完全刪除。這些欄位包括：@generated，@version，site，和spider。該變化不會影響任何正常的DAST操作，但會影響以自動方式使用JSON報告並使用這些欄位的使用者。

在GitLab 14.0中，DAST .gitlab-ci.yml將刪除當前模板中定義的階段，以避免模板覆蓋DAST使用者進行的手動更改的情況。該更改是為了響應客戶的問題，其中模板的階段與自定義DAST配置一起使用時會引起問題。變化後，gitlab-ci.yml未指定dast階段的配置必須更新為包括此階段。

在GitLab Runner 13.1（版本3376）中，介紹了Shell執行器sigterm，然後介紹sigkill了該過程。還引入了一個新的功能標誌，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此可以使用以前的過程終止序列。在GitLab Runner 14.0中，將刪除功能標記。

從GitLab 13.8開始，不建議使用CI/CD掃描的DAST域驗證的當前方法。

在GitLab 14.0中，舊的DAST驗證方法將被刪除。這種域驗證方法僅在DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED環境變數true在gitlab-ci.yml檔案中設定為且Gitlab-DAST-Permission站點上的標頭未設定為的情況下才禁止掃描allow。這種分兩步的方法造成了一種情況，使用者必須選擇退出使用該變數，然後才能退出使用標題。對於擔心保護網站免受全面，主動掃描的使用者而言，仍然可以透過在任何網站上新增Gitlab-DAST-Permission值為的標頭來撤銷對GitLab DAST掃描的許可deny。這將繼續阻止對包含此HTTP標頭的任何網站進行的GitLab DAST掃描。

在GitLab Runner 13.2中翻譯step_script到build_script被新增到自定義執行。在14.0中，" build_script"階段將替換為" step_script"

預設DAST Spider從目標URL開始進行抓取

變更日期：2021年6月22日

在GitLab 14.0中，DAST_SPIDER_START_AT_HOST將更改新變數的預設值，false以更好地支援使用者意圖在指定的目標URL（而不是主機根URL）開始爬網和掃描。除了開始對指定的URL進行爬網外，如果指定的路徑不包含指向整個站點的連結，則掃描的時間也將更少，也將帶來額外的好處。這將使更輕鬆地掃描應用程式的較小部分，而不是每次掃描都對整個應用程式進行爬網。

升級更新Omnibus版本升級

Omnibus安裝的自建例項可直接使用Linux包管理器可以升級。例如對CentOS:

yum install gitlab-ce

就能自動完成升級：

sudo docker stop gitlabsudo docker rm gitlab

然後Pull官方最新映象：

sudo docker pull gitlab/gitlab-ce:latest

重新啟動容器（啟動引數和以前保持一致）即可，比如:

sudo docker run --detach \--hostname gitlab.example.com \--publish 443:443 --publish 80:80 --publish 22:22 \--name gitlab \--restart always \--volume /srv/gitlab/config:/etc/gitlab \--volume /srv/gitlab/logs:/var/log/gitlab \--volume /srv/gitlab/data:/var/opt/gitlab \gitlab/gitlab-ce:latest

Docker compose安裝版本

透過：

docker-compose pulldocker-compose up -d