按照慣例GitLab發佈有一個新的月度版本13.4.，本次發佈主要帶來了Vault for CI變量，Kubernetes Agent和S安全中心能功能幫助團隊降低風險，提高效率並加快交付速度，並提升到安全性，降低漏洞，提高效率，使用戶體驗更好，並幫助的團隊更快地部署等。請追隨蟲蟲一起來學習一下GitLab 13.4帶來的新的功能。

概述

本月的發行版爲GitLab DevSecOps套件增加了一些功能。首先，作爲構建和部署過程的一部分，現在可以將存儲在HashiCorp Vault中的機密注入CI/CD作業中。

代碼部署職責分開的組織可以通過Reporter訪問Deployer角色來提升特定用戶。部署者角色遵循最小特權訪問的原則，允許他們批准合併請求並將代碼部署到受保護的環境，而無需訪問修改代碼本身。

降低風險的另一種方法是使用新的GitLab Kubernetes代理。運營商可以從GitLab部署到其Kubernetes羣集，而無需將其羣集打開到整個網絡。GitLab託管Terraform狀態的新Terraform狀態文件引入自動版本控制支持，以支持合規性和調試需求。最後但並非最不重要的一點是，"實例安全性"儀表板已演變爲具有漏洞報告和設置功能的GitLab安全中心。

通過從搜索欄進行快速導航來快速跳轉到最近的問題，組，項目，設置和幫助主題，從而改進了全局搜索功能。對於GitLab頁面重定向，能夠重定向站點中的各個頁面和目錄，這使用戶能夠更高效地部署頁面站點。

對於那些希望獲得增強的部署信息的人，新版本使可以從環境儀表板管理數百個受支持的項目部署。

GitLab 13.4主要功能改進

介紹GitLab Kubernetes代理（PREMIUM及以上）

長期以來，GitLab的Kubernetes集成使無需手動設置即可部署到Kubernetes集羣。許多用戶都喜歡易用性，而其他用戶則遇到了一些挑戰。當前的集成要求集羣對Internet開放，供GitLab訪問。對於許多組織來說，這是不可能的，因爲他們必須出於安全性，合規性或監管目的而鎖定羣集訪問。

最新的GitLab版本中發佈了GitLab Kubernetes代理：一種部署到Kubernetes集羣的新方法。

該代理在集羣內部運行，無需將其打開到網絡。代理通過從GitLab提取新更改來協調部署，而不是GitLab將更新推送到集羣。無論使用哪種GitOps方法，GitLab都可以滿足的要求。

注意，這這次發佈是代理的第一個版本。當前，GitLab Kubernetes代理具有配置驅動的設置，並可以通過代碼進行部署管理。儘管不支持某些現有的Kubernetes集成功能，例如Deploy Boards和GitLab Managed Apps，將在未來迭代中最終實現這些功能，並與代理提供注重安全性和合規性的集成。

在GitLab Starter中提供了功能標記（STARTER及以上）

GitLab 11.4中引入了功能標記。在12.2中，GitLab引入了百分比推廣和用戶ID功能標記策略。在13.1中，引入了功能標記用戶列表，並支持每個環境多個功能標記策略。

今年早些時候，GitLab承諾將18個功能免費發佈到CE產品中。在該版本的已經完成了將功能標誌移動到Starter的工作，並且繼續將功能標誌服務遷移，在GitLab 13.5中在Core免費發佈。

使用搜索欄快速導航

在GitLab上瀏覽時，有時只想轉到特定項目而不是搜索結果頁面。

使用全局搜索欄，在新版本中可以快速跳轉到最近的問題，組，項目，設置和幫助主題。甚至還可以使用/鍵盤快捷鍵將光標移至搜索欄，從而更有效地導航。

MR差異內部的內聯代碼覆蓋率備註

在查看合併請求時，很難確定修改後的代碼是否包含在單元測試中。審閱者可以改爲依賴總體覆蓋範圍值，並要求在批准合併請求之前增加該值。這可能會導致開發人員採用分散的測試編寫方法，但實際上可能無法提高代碼質量或覆蓋範圍。

現在，開發人員在進行審閱時將在合併請求差異中看到代碼覆蓋率的可視化表示。該可視指示器可以輕鬆查看修改後的代碼是否包含在單元測試中，從而有助於加快代碼審閱以及合併和部署功能的時間。

使用環境儀表板大規模跟蹤環境（PREMIUM及以上）

從GitLab 12.5開始，使用環境面板只能在3個項目中看到7個環境。通過對儀表板進行分頁來幫助大規模支持和管理環境，新改的GitLab 13.4中的環境儀表板，可以在項目中看到更多環境。

GitLab Terraform維護權

最近已經獲得了GitLab Terraform提供程序的維護者權利，並計劃在即將發佈的版本中對其進行增強。在過去的一個月中，GitLab合併了21個請求請求並關閉了31個問題，其中包括一些長期未解決的錯誤和缺少的功能（如支持實例集羣）。可以在Terraform文檔中閱讀有關GitLab Terraform提供程序的更多信息。

使用OpenAPI規範或HAR文件進行API模糊測試（ULTIMATE）

API模糊測試是在Web應用程序和API中查找其他掃描程序和測試技術所缺少的錯誤和漏洞的好方法。

GitLab的API模糊測試可讓提供OpenAPI v2規範或應用程序的HAR文件，然後自動生成旨在解決極端情況並查找錯誤的隨機輸入。然後，結果立即顯示爲管道的一部分。

這是API模糊測試的第一個版本，後續將會持續改。

在用戶界面中預覽新的指標圖表

在GitLab指標儀表板中創建圖表具有挑戰性。在儀表板YAML文件中定義了圖表之後，在master不知道新創建的圖表就是想要的內容的情況下，會誤提交更改了。

從GitLab 13.3開始，可以在創建圖表時預覽面板的YAML，從而在將更改提交到儀表板的YAML文件之前獲得早期反饋。

組中所有項目的代碼覆蓋率數據（PREMIUM及以上）

當的團隊管理多個GitLab項目時，應該能夠輕鬆地看到一個數據點，該數據點顯示了所有項目中代碼覆蓋率隨時間的變化趨勢。以前，可視化此趨勢涉及繁瑣的手動操作，需要從每個項目中下載覆蓋率數據並將其插入電子表格中。

現在，以團隊負責人的身份，可以快速輕鬆地收集每個小組項目或選定項目中可用的所有代碼覆蓋率數據作爲.csv文件。這是一項MVC功能，隨後將可以繪製隨時間變化的平均覆蓋範圍。

對語言覆蓋測試的新語言支持（ULTIMATE）

此版本在覆蓋率指導的模糊測試中引入了對多種新語言的支持。

現在，可以對以Java，Rust和Swift編寫的應用程序進行模糊測試的所有功能，以發現其他進程遺漏的錯誤和安全漏洞！

在環境索引頁面中顯示告警（ULTIMATE）

環境頁面顯示了環境的一般狀態。在此版本中，通過添加告警改進了環境頁面。在環境狀態旁邊看到觸發的告警，可以立即採取措施進行補救。

子管道現在可以觸發自己的子管道

使用父/子管道時，子管道現在可以觸發自己的子管道。當希望靈活地生成可變數量的子管道時，這種增加的深度可能很有用。

在使用父/子配置之前，每個子管道都需要在父中手動定義的觸發作業。現在，可以生成動態觸發任意數量的新子管道的子管道。例如，如果有monorepo，則可以根據分支中的更改動態生成第一個子管道，該子管道本身會生成可變數量的新子管道。

改進了父子管道之間的導航

在父管道和子管道之間進行導航比較麻煩，需要多次單擊。區分哪個作業觸發了哪個子管道也不容易。現在，可以更輕鬆快捷地查看父管道與子管道的連接方式。

並行矩陣作業在作業名稱中顯示相關變量

如果使用矩陣作業，可能會注意到很難確定每個作業使用的矩陣變量，因爲作業名稱的格式類似於matrix 1/4。在13.4中，現在將看到在該作業中使用的相關變量值，而不是看到通用作業名稱。例如，如果要構建x86體系結構的調試目標，則該作業現在將命名爲matrix: debug x86。

連接Atlassian帳戶

GitLab用戶現在可以將其GitLab帳戶連接到其Atlassian Cloud帳戶。連接帳戶允許用戶使用其Atlassian憑據登錄GitLab。此更改也爲將來增強Gitlab Jira集成以及與Atlassian套件中的其他產品集成奠定了基礎。

Core中現已提供相關問題和更多內容

幾個月前，GitLab宣佈了開放18種功能的計劃。爲了兌現這一承諾，Core中現在提供了相關問題，問題CSV導出和問題委員會重點模式。這僅適用於"關聯"關係。"阻止"和"被阻止"保留在付費層中。

在合併請求側欄中顯示源分支名稱

在查看代碼更改，討論和合並請求中的提交時，通常需要在本地檢出分支以進行更深入的查看。但是，隨着更多滾動內容的出現，隨着更多內容添加到合併請求描述中，查找分支名稱變得更加困難。

現在已將分支名稱添加到合併請求側欄中，從而使其可以隨時輕鬆訪問，並且無需滾動。就像合併請求參考一樣，源分支部分提供了一個方便的"複製"按鈕，可以方便地進行本地檢出。

在合併請求差異中強調摺疊差異

將更改應用於多個文件的合併請求有時會摺疊大文件差異，以提高性能。發生這種情況時，很容易忽略文件而不查看它，尤其是在合併具有多個文件的請求中。從GitLab 13.4開始，合併請求將強調包含摺疊文件的差異，這將確保在代碼審閱過程中審閱者不會丟失這些文件。

在設計視圖中將待辦事項標記爲完成

GitLab中的有效溝通取決於待辦事項列表。如果在評論中被提及，那麼能夠遵循待辦事項並採取行動或將其標記爲已完成至關重要。當需要記住做某事或稍後再回來時，能夠自己做事也很重要。

直到現在，都無法在設計上添加待辦事項或將其標記爲已完成，這令人非常沮喪。這確實削弱了產品團隊之間的溝通效率，因爲待辦事項對於在GitLab中管理工作流程至關重要。

從13.4版開始，設計可以與問題註釋保持一致，並且可以使用待辦事項以獲得更加一致和有用的體驗！

文件摺疊時對合並請求差異的警告

在合併請求diff上摺疊大文件是爲了增強合併請求中diff部分的性能和響應能力。但是，在代碼檢查期間，由於滾動了大文件，檢查者在滾動文件列表時可能會丟失某些文件。

合併請求差異頁面的頂部引入了可見警告，明確告知用戶該部分中的文件已摺疊。這樣可以確保對合並請求中的所有相關更改進行審覈。

改進的CI/CD故障排除指南

新改進了GitLab CI CD故障排除指南，其中包含有關可能遇到的常見問題的其他信息。希望改進後的文檔是寶貴的資源，可幫助使GitLab CI/CD輕鬆快速地啓動並運行。

合併請求並非意外從合併中刪除（PREMIUM及以上）

以前，合併請求可能會因後期評論而意外地從合併中刪除。如果合併請求已經在合併火車上，並且有人添加了一個註釋，該註釋創建了一個新的未解決的線程，則該合併請求被認爲是不可合併的，並從火車上刪除了。現在，在將合併請求添加到之後，可以進行新註釋，而無需擔心破壞合併過程。

顯示MR中代碼覆蓋率值的作業數據

作爲開發人員，即使在複雜的情況下（例如，管道中有多個要解析的工作來計算覆蓋率值的情況），也應該能夠在管道完成運行後輕鬆查看代碼覆蓋率。到目前爲止，"合併請求"窗口小部件僅顯示這些值的平均值，這意味着必須導航到作業頁面，然後返回到"合併請求"本身以獲取有關覆蓋範圍值的更詳細的詳細信息。爲了節省的時間並消除這些額外的步驟，現在向介紹平均覆蓋率值，它與目標分支和源分支的關係以及工具提示，該提示顯示用於計算平均值的每個作業的覆蓋率。

查看組時刪除程序包註冊表程序包

GitLab軟件包註冊表是存儲和共享各種軟件包格式的地方。當項目或組中有大量軟件包時，希望快速識別未使用的軟件包並將其刪除，以防止人們安裝錯誤的軟件包。可以使用Packages API或Package Registry用戶界面從註冊表中刪除軟件包。但是，直到最近，仍無法在UI中查看組時刪除軟件包。

現在，可以在查看組的程序包註冊表時刪除程序包。只需導航到組的Package Registry，按軟件包名稱過濾，然後刪除所有不需要的軟件包。

將conan的範圍擴展到項目

可以使用GitLab Conan存儲庫發佈和共享C/C++依賴項。但是，程序包以前只能限於實例。這是有問題的，因爲Conan軟件包名稱必須少於或等於51個字符。對於任何試圖發佈位於小組之內的軟件包的人，gitlab-org/ci-cd/package-stage/feature-testing/conan使用該功能幾乎是不可能的。

現在，可以將Conan軟件包的作用域限定爲一個項目，從而可以輕鬆發佈和共享項目的依賴項。

在合併請求中設置"管道成功合併時"時的通知

當審閱者將合併請求（MR）設置爲管道成功合併（MWPS）時，不會發送電子郵件通知。MR合併後，必須手動檢查以查看狀態或等待通知。在此版本中，通過在審閱者將MR設置爲MWPS時自動通知合併請求線程中的所有訂閱者來解決此問題。

使用用戶指定的Kubernetes版本創建EKS集羣

GitLab用戶現在可以選擇要在EKS上配置的首選Kubernetes版本。與EKS上支持的Kubernetes版本保持一致，用戶可以在1.14-1.17版本之間進行選擇。

將事件創建爲問題類型

並非所有出現的問題都會首先觸發告警：客戶報告故障，團隊成員確定性能問題。現在，事件是一種問題，因此團隊成員可以通過熟悉的工作流程快速創建事件。在GitLab中的任意位置單擊"新問題"，然後在"類型"字段中選擇"事件"。

Markdown中的參考GitLab告警

在GitLab風格的Markdown中添加了特定於告警的參考，從而改進了告警，使可以輕鬆共享和參考告警。用於^alert#1234在事件，問題或合併請求中的任何Markdown字段中引用告警。此告警參考還可以幫助確定告警產生的待辦事項，而不是問題或合併請求。

查看事件的告警有效負載

告警的有效負載包含診斷故障和恢復服務的關鍵信息，並且該信息必須易於訪問，因此在解決事件時無需切換工具或選項卡。通過告警創建的事件會在"告警詳細信息"選項卡中顯示告警的全部有效負載。

高級搜索中的搜索結果快75%（STARTER及以上）

在GitLab 13.4中，當僅限於特定的名稱空間和項目時，高級搜索現在將結果輸出速度提高75%。

管理員的已刪除項目視圖

12.6中引入了延遲項目刪除的功能。但是，以前沒有辦法將所有待刪除的項目集中在一處。現在，自建實例的管理員可以在單個視圖中查看所有待刪除項目，以及可以輕鬆還原這些項目的按鈕。

此功能使自建實例的管理員可以通過在單個位置彙總此信息並提供撤消不希望的刪除活動的機會來更好地控制項目刪除。

向API添加了組推送規則支持（STARTER及以上）

以前，只能通過GitLab UI分別訪問每個組並應用這些規則來配置組推送規則。現在，可以通過API管理這些規則，以支持自定義的GitLab工具和自動化。

靜態站點編輯器的配置文件

在GitLab 13.4中，新引入了一種配置靜態站點編輯器的新方法。儘管配置文件在此版本中不存儲或檢索任何值，但爲自定義編輯器行爲奠定了基礎。

在即將發佈的版本中，將爲添加值，.gitlab/static-site-editor.yml以設置網站的基本URL，從編輯器上傳的圖像的存儲位置，覆蓋Markdown語法首選項和其他特定於編輯器的設置。

靜態站點編輯器編輯

前端問題是一種靈活方便的方法，可以在旨在由靜態站點生成器解析的數據文件中定義特定於頁面的變量。它通常用於設置頁面的標題，佈局模板或作者，但是當頁面呈現爲HTML時可以用於將任何類型的元數據傳遞給生成器。每個數據文件的最頂部都包含前端內容，通常將其格式化爲YAML或JSON，並且需要一致且準確的語法。不熟悉特定語法規則的協作者可能會無意中引入無效的標記，從而可能導致格式問題甚至構建失敗。

靜態站點編輯器的WYSIWYG編輯模式已經從編輯器中刪除了前端內容，以防止出現這些格式錯誤。

在GitLab 13.4中，可以在一個熟悉的基於表單的界面中訪問和編輯每個前沿問題字段的值。單擊"設置"按鈕將顯示一個面板，該面板顯示定義的每個鍵的表單字段。使用當前值填充字段，編輯其中的任何一個就像在Web表單中鍵入一樣簡單。以這種方式編輯主題，可以避免語法複雜性，並可以完全控制內容，同時確保最終輸出的格式一致。

適用於Jira的GitLab和DVCS連接器現已加入Core

對於Jira GitLab的用戶，GitLab for Jira應用程序和DVCS Connector 允許顯示有關GitLab提交的信息並直接在Jira中合併請求。結合與Jira的本地集成，可以在工作時輕鬆地在兩個應用程序之間來回移動。

在Web IDE中支持自定義JSON模式驗證（PREMIUM及以上）

依靠人們以JSON或YAML格式編寫配置的項目可能會引起問題，因爲很容易打錯字並弄亂事情。可以編寫在CI管道中捕獲此驗證工具，但是使用JSON模式文件有助於提供文檔和提示。

項目貢獻者可以.gitlab/.gitlab-webide.yml在其存儲庫中的文件中定義自定義架構路徑，該路徑指定要驗證的文件的架構和路徑。在Web IDE中加載定義的文件時，將顯示其他反饋和驗證，以幫助創建文件。

有向無環圖（DAG）關係限制增加到50

如果使用的是有向非循環圖（DAG）管道，則可能會發現一個作業可以列出的10個作業的限制needs:是不夠的。在13.4中，默認限制從10增加到50，以允許管道中的作業之間的關係網絡更加複雜。

通過跳過作業改善了"需求"的行爲

在某些情況下，對於needs依賴項，管道中跳過的作業有可能被認爲是成功的，這允許以後的作業本來可以運行。此問題已在13.4中修復，並且可以正確處理跳過的作業的行爲needs。

鎖定最新的作業工件以防止刪除

GitLab現在將自動在任何活動分支，MR或標籤上鎖定成功作業和管道的最新工件，以防止其根據過期時間被刪除。這使設置更激進的到期策略來清除較舊的工件變得更容易，有助於減少磁盤空間消耗，並確保始終從管道中獲得最新工件的副本。

CI/CD的管道效率指南

優化的CI / CD管道運行可以提高速度並節省成本。通過簡短指南來改進文檔，以使充分利用優化管道的優勢。

測試報告按測試狀態排序

單元測試報告是看到從管道的所有測試結果的簡單方法。但是，如果有大量測試，則查找失敗的測試可能很耗時。導致報表難以使用的其他問題包括難以滾動長的跟蹤輸出，並且對於少於1秒的測試，數據通常四捨五入爲0。現在，默認情況下，"測試報告"首先將失敗的測試排在報告的頂部，然後再按持續時間排序。這使查找故障和長時間運行的測試變得更加容易。而且，測試的持續時間現在以毫秒或秒爲單位顯示，因此讀取速度更快，並且以前的滾動問題也已解決。

文件大小上傳到Package Registry的限制

現在存在一些限制，這些限制限制了可以上傳到GitLab軟件包註冊表的軟件包文件的大小。添加限制是爲了防止濫用並優化Package Registry的性能。限制因包裝格式而異。對於GitLab在線倉，最大文件大小爲：

· Canon：250MB

· Maven：3GB

· NPM：300MB

· NuGet：250MB

· PyPI：3GB

對於自建實例，默認設置相同。但是，管理員可以使用Rails控制檯更新限制。

使用CI_JOB_TOKEN發佈PyPI軟件包

可以在源代碼和CI/CD管道旁邊使用GitLab PyPI存儲庫來構建，發佈和共享python軟件包。但是，以前無法通過使用預定義的環境變量來對存儲庫進行身份驗證CI_JOB_TOKEN。結果，被迫使用個人憑據來更新PyPI存儲庫，或者可能決定完全不使用存儲庫。

現在，使用GitLab CI/CD通過預定義的CI_JOB_TOKEN環境變量來發布和安裝PyPI軟件包比以往更加容易。

GitLab頁面的簡單重定向配置文件

對於GitLab Pages的用戶，希望更好地管理URL更改，則會遇到無法在GitLab Pages站點中管理重定向的痛苦。現在，GitLab允許通過將配置文件添加到存儲庫來配置規則，以將Pages站點的一個URL轉發到另一個URL。

GitLab託管Terraform

對於合規性和偶爾的調試需求，必須具有訪問Terraform狀態的先前版本的權限。從GitLab 13.4開始提供對GitLab受管Terraform狀態的版本控制。新的Terraform狀態文件的版本控制會自動打開。現有的GitLab託管Terraform狀態文件將在以後的版本中自動遷移到版本存儲。

突出顯示事件的關鍵告警詳細信息

在對事件進行分類時，應該很容易確定告警已打開多長時間以及事件已觸發了多少次。這些細節通常在確定客戶影響以及團隊現在需要做出響應時至關重要。在新的事件突出顯示欄中，顯示了告警的開始時間，事件計數，以及指向原始告警前端和中心的鏈接。此信息可用於告警引發的事件。

設置和編輯事件嚴重性

事件的嚴重性告訴響應者和利益相關者中斷的影響以及響應所需的方法和緊迫性。當團隊在故障處理過程中共享發現並補救中斷時，可以編輯事件的嚴重性。現在，可以在"事件詳細信息"頁面的右側邊欄中編輯事件的嚴重性，嚴重性將顯示在事件列表中。

創建，編輯和刪除容器網絡策略（ULTIMATE）

容器網絡策略編輯器的這一改進使用戶可以直接在GitLab UI中輕鬆創建，編輯和刪除其策略。該編輯器的功能包括.yaml爲經驗豐富的用戶提供的模式和爲不熟悉網絡策略的用戶提供的直觀規則編輯器UI。可以在"安全性和合規性">"威脅管理">"策略"中找到新的策略管理功能。

Azure Blob存儲支持

GitLab和GitLab Runner現在都支持Azure Blob存儲，這使得在Azure上運行GitLab服務變得更加容易。

GitLab實例支持所有對象存儲類型的Azure，包括：LFS文件，CI工件，備份等。若要配置Azure Blob存儲，請按照Omnibus或Helm Chart安裝的說明進行操作。

GitLab Runners還支持Azure來存儲分佈式緩存。可以使用該[runners.cache.azure]部分配置Azure存儲。

適用於Ubuntu和OpenSUSE的Omnibus ARM64軟件包（ULTIMATE）

爲了響應對在64位ARM架構上運行GitLab的支持的需求不斷增長，很高興地宣佈正式提供ARM64 Ubuntu 20.04 Omnibus軟件包。要下載並安裝Ubuntu 20.04軟件包，轉"安裝"頁面並選擇Ubuntu。

安全和合規性審計

安全中心（ULTIMATE）

如今，實例級別的漏洞管理經驗在功能和靈活性上都受到限制。當前的經驗是一個頁面，其中結合了漏洞詳細信息，指標可視化和配置。沒有足夠的空間來擴展這些功能或利用其他安全功能。

對GitLab中的安全可見性和管理進行了根本性的更改。實例安全儀表板已轉換爲安全中心。最大的變化是引入了新的菜單結構。現在，可以找到一個"安全儀表板"，"漏洞報告"和"設置"區域，而不是單個頁面。儘管功能沒有改變，但將其分解可以實現將來的增強，否則這些增強將是困難的。這還將創建一個頂層框架，以在將來包含其他與安全性相關的功能。

專用的漏洞報告現在具有更多空間來顯示重要詳細信息，並繼承了當前在項目漏洞列表中找到的詳細信息。將漏洞度量小部件分隔到各自的區域中可以創建一個真正的安全儀表板。現在，它是用於將來的可視化的專用畫布，不僅用於管理漏洞，而且還用於與安全相關的任何指標。最後，將"設置"拆分爲自己的區域可爲"漏洞管理"之外的實例級安全配置創建新的共享空間。

導出所有合併提交的列表（ULTIMATE）

注重合規性的組織需要一種方法來向審覈員展示與生產中任何特定更改有關的組件的整體視圖。在GitLab中，這意味着連接所有點：MR，問題，管道，安全掃描以及其他有關提交的數據。到現在爲止，必須挖掘GitLab應用程序和/或構建自定義工具來彙總信息-這不是很有效。

現在，可以以編程方式收集和導出此數據以滿足審覈要求，或者通過導航到"合規性儀表板"並單擊按鈕以導出該組的所有合併提交的列表來執行其他分析。生成的文件將包含所有合併提交及其作者，相關的合併請求ID，組，項目，批准者等。

通過API列出和撤消個人訪問令牌（ULTIMATE）

管理對GitLab名稱空間的訪問是合規性計劃的重要組成部分。從最小特權的原則到及時終止訪問，GitLab中有一些與個人訪問令牌相關的合規性要求。爲了在命名空間中支持對這些用戶憑據的更輕鬆，更好，更批量的管理，新引入了列出所有用戶PAT並可以選擇通過API撤消它們的功能。

對GitLab API功能的這些改進使用戶可以列出和撤消其自己的PAT，並使管理員可以列出和撤消其用戶的PAT。管理員現在可以更好地瞭解誰有權訪問其名稱空間，可以對用戶的憑據做出數據明智的決定，並有權撤銷可能已遭到破壞或可能超出公司的證書輪換政策的PAT。

授予用戶部署權限，而無需訪問代碼（PREMIUM及以上）

如果團隊需要在擁有開發的團隊成員和擁有部署的團隊成員之間保持職責分離，則GitLab中的權限範式使這一挑戰變得棘手。

在GitLab 13.4中，可以授予非代碼貢獻者權限以批准合併請求進行部署，並實際部署代碼，而無需授予他們維護者訪問權限。

在CI作業中使用HashiCorp Vault機密（PREMIUM及以上）

在GitLab 12.10中，GitLab引入了GitLab Runner的功能，以獲取機密並將其注入CI作業。GitLab現在通過在文件中構建新語法來擴展JWT Vault身份驗證方法。這使可以更輕鬆地在GitLab上配置和使用HashiCorp Vault。

擴展依賴項掃描支持的程序包管理器和語言

將使用NuGet 4.9+或Conan軟件包管理器的C，C ++，C＃和.Net項目的依賴項掃描添加到GitLab支持的語言和框架中。作爲安全階段的一部分，可以啓用依賴項掃描來檢查程序包管理器中包含的依賴項是否存在已知漏洞。這些漏洞及其嚴重性級別將顯示在合併請求中，因此可以在合併前瞭解新依賴項可能帶來的風險。還可以將項目配置爲對嚴重性爲"嚴重"，"高"或"未知"的任何漏洞要求合併請求批准。

撤銷用於自我管理的憑證庫存的PAT

證書庫存提供了洞察管理員需要管理用戶訪問憑據GitLab實例。隨着注重合規性的組織在憑據管理策略的嚴格性方面的差異，新添加了一個按鈕，管理員可以選擇撤消用戶的個人訪問令牌（PAT）。管理員現在可以輕鬆撤消可能已遭到破壞的PAT。此功能爲需要更靈活的實施選項的組織提供支持，以最大程度地減少對用戶的干擾。

按需DAST掃描儀配置文件（ULTIMATE）

除了最新發行版中引入的DAST按需掃描外，DAST掃描器配置文件還允許快速創建多個配置文件，以涵蓋多種掃描類型，從而擴展了這些掃描的配置選項。在13.4中，"掃描程序配置文件"最初包括"蜘蛛超時"選項，該選項設置DAST蜘蛛在嘗試發現要掃描站點的所有頁面時應運行多長時間。它還包含一個目標超時選項，用於設置掃描器在站點未響應200或300狀態碼的情況下，應等待多長時間才能中止掃描。在後續版本中繼續迭代此功能，更多配置選項將添加到"掃描儀配置文件"中。

Gitlab Geo高可用集羣更新

Gitaly Cluster自動存儲庫修復

當主要的Gitaly Cluster節點脫機時，該節點上的存儲庫被標記爲只讀，以防止在未複製的更改發生時丟失數據。如果節點重新聯機，則GitLab不會自動恢復，管理員必須手動觸發，否則，必須接受數據丟失。其他情況也可能導致存儲庫過時或只讀，例如無法在輔助節點上處理複製作業。在這種情況下，存儲庫將保持過期，直到再次進行寫入並觸發複製作業爲止。

爲了解決這些情況，Praefect現在計劃在一個節點上檢測到過時的存儲庫但在另一節點上檢測到存儲庫的最新版本時安排複製作業。此複製作業會自動將過期的存儲庫更新爲最新狀態，從而減輕了對手動數據恢復的擔憂。自動修復還可以確保在複製作業失敗時快速將輔助節點恢復到最新狀態，而不必等待下一次寫入發生。由於許多Gitaly羣集存儲大量存儲庫，因此這大大減少了管理員和站點可靠性工程師在故障轉移後需要花費時間來恢復數據的時間。

此外，自動修復啓動將存儲庫複製到添加到羣集的任何新Gitaly節點的功能，從而在添加新節點時無需手動干預。

Gitaly Cluster多數表決支持（測試版）

Gitaly Cluster允許在多個熱Gitaly節點上覆制Git存儲庫。通過消除單點故障來提高容錯能力。在GitLab 13.3中引入的參考事務導致更改被廣播到集羣中的所有Gitaly節點，但是隻有與主節點一致投票的Gitaly節點纔會將更改保存到磁盤。如果所有副本節點都不同意，則僅將一個更改副本保留到磁盤上，從而造成單點故障，直到異步複製完成。

多數表決支持通過要求多數節點在保留對磁盤的更改之前達成一致來提高容錯能力。啓用功能標誌後，寫入必須在多個節點上成功進行。異議節點通過異步複製自動地從形成仲裁的節點開始同步。

GitLab Helm chart改進

現已提供證書映像的RedHat通用基本映像（UBI）版本。以前，使用基於UBI映像的部署需要對證書容器使用非UBI映像。要使用此新映像部署GitLab，請global.certificates.image.tag=master-ubi8在values.yaml文件中指定。

Helm安裝現在支持智能卡身份驗證。

子圖表已添加，用於部署和配置Praefect服務。Praefect允許跨Gitaly節點集羣管理Git存儲庫的存儲，以實現容錯配置。

下載到Workhorse的存檔文件的緩存已針對Helm圖表安裝被禁用。從Omnibus安裝方法開始將存檔緩存存儲在本地磁盤上。在Kubernetes部署中，磁盤不會在Pod之間共享。存檔會隨着時間的推移而累積，因爲無法清理存檔文件。這可能會導致節點上磁盤使用率過多的問題。

現在可以在圖表中啓用內容安全策略（CSP），以幫助防止JavaScript跨站點腳本（XSS）攻擊。

對GitLab Helm圖表的智能卡身份驗證支持（ULTIMATE）

現在，可以使用諸如通用訪問卡（CAC）之類的智能卡對通過Helm圖表部署的GitLab實例進行身份驗證。使用X.509證書針對本地數據庫對智能卡進行身份驗證。這使Helm圖表與Omnibus部署中可用的智能卡支持相當。

Omnibus的改進

現在支持在ARM64上部署GitLab。

此發行版包括PostgreSQL的次要版本更新，從11.7到11.9，以及從12.3到12.4。

GitLab 13.4包括Mattermost 5.26。此版本包括通過實驗性的側邊欄增強功能對頻道進行分類和重新排序的功能，通過"詢問社區"鏈接從Mattermost社區獲得幫助的功能，以及更多功能。它還包括安全更新。建議從早期版本升級。

Gitlab Runner 13.4

還將發佈GitLab Runner 13.4。GitLab Runner與GitLab CI/CD協同工作，GitLab CI/CD是GitLab附帶的開源持續集成服務。新功能包括：

將存儲在Hashicorp Vault服務器中的機密用於CI/CD作業變量；

將Azure Blob存儲用於運行程序緩存；

添加userns_mode對Gitlab CI服務的支持；

允許覆蓋Kubernetes執行者的Service容器資源；

允許覆蓋Kubernetes執行器的Helper容器資源；

添加Kubernetes節點關聯性設置。

Bug修復：

修復：使用PowerShell時，文件類型變量具有字節順序標記；

修復：Docker身份驗證隨機行爲；

修復：Docker Windows Git克隆；

所有更改的列表都在GitLab Runner CHANGELOG中。

性能改進

在每個版本中，GitLab將繼續在改善性能方面取得重大進展。致力於提高每個GitLab實例的速度。

在GitLab 13.4中，在問題，項目，里程碑等方面提高性能。GitLab 13.4的一些改進包括：

修復具有N ^ 2個查詢的軟件包版本渲染結果；

在某些情況下，將"設置">"通知"的加載時間從60s減少到2s；

具有較大描述的合併請求不再超時；

改善Snowplow遙測性能；

修復一些N + 1 GraphQL查詢；

地理位置：提高打包文件查詢的性能。

功能變化

Debian Jessie和Raspbian Stretch不再受支持

變更日期：2020年9月22日

Debian Jessie和Raspbian Stretch在2020年6月結束支持，GitLab 13.4不提供支持。GitLab 13.3是這些發行版的最後一個受支持的版本。請訪問"不推薦使用的操作系統"頁面以獲取更多信息。

刪除容器註冊表日誌格式化程序

變更日期：2021年1月22日

當前，GitLab支持針對應用程序日誌的text/json/logstash日誌格式和針對訪問日誌的text/json/combined。將刪除logstash和組合格式，僅使用兩個選項（文本（用於開發）和json）統一應用程序和訪問日誌的格式化程序。

刪除Container Registry日誌hook

變更日期：2021年1月22日

Container Registry支持日誌hook，目前僅可用於電子郵件通知。

如今，基於日誌條目的告警通常由單獨的工具處理。此功能的實現與底層日誌記錄庫緊密耦合，這是在不影響可用功能的情況下切換依賴關係的能力的限制。

爲了簡化註冊表功能和配置，將刪除對日誌記錄掛鉤的支持。

刪除Container Registry maxidle和maxactive Redis池設置

變更日期：2021年1月22日

當前爲Redis連接池公開的一些配置設置與基礎Redis客戶端綁定，並且在替代庫中沒有等效設置。在開始改進Redis集成（例如增加對Sentinel的支持）的過程中，決定開始着手以功能更豐富，支持更好的替代方法來替換當前的Redis客戶端依賴項。爲此，需要替換綁定到當前客戶端庫的當前Redis池配置設置。

計算刪除redis.pool.maxidle和redis.pool.maxactive設置，並添加redis.pool.size（最大連接數），redis.pool.minidle（最小空閒連接數）和redis.pool.maxlifetime（可以重新使用連接的最大時間）。

刪除Container Registry代理穿透緩存

變更日期：2021年1月22日

有些容器註冊表功能已過時或不再使用（至少在GitLab上）。支持這些功能限制了清理代碼庫並減少第三方依賴項列表的能力。

本proxy部分允許將Container Registry設置爲上游存儲庫的本地鏡像。在用於GitLab部署的註冊表環境中，這樣做的用處不大，用戶很可能會將其註冊表部署與GitLab實例放在一起，而不是使用託管在單獨基礎架構（例如Docker Hub）上的註冊表服務。

刪除對Bugsnag的Container Registry支持

變更日期：2021年1月22日

Bugsnag是容器註冊表支持的錯誤報告服務之一。據統計，沒有一個用戶依賴此服務，在GitLab 使用Sentry。爲了簡化和整合支持的錯誤報告服務，打算增加對Sentry的支持，並刪除對Bugsnag的支持。

刪除對NewRelic的Container Registry支持

變更日期：2021年1月22日

NewRelic是容器註冊表支持的錯誤報告服務之一。據統計，沒有一個用戶依賴此服務，打算添加對Sentry的支持，並刪除對NewRelic的支持。

刪除使用Docker註冊表API v1的請求

變更日期：2021年1月22日

GitLab將於2021年1月22日通過Docker註冊表v1 API禁用拉取功能.Docker在2019年6月棄用，此功能使GitLab團隊可以專注於針對當前註冊表用例的功能和修復程序。

對CentOS 6的支持終止

變更日期：2020年11月22日

CentOS 6將於2020年11月停止官方支持。GitLab 13.6將是在CentOS 6上部署GitLab的最後一個受支持版本。建議升級到CentOS 7或8。請訪問不推薦使用的OS頁面，以獲取有關受支持發行版的更多信息。

舊功能標記設爲只讀

變更日期：2020年9月22日

舊版功能標誌將變爲只讀。它們仍然可以使用，但是不能僅通過API通過UI進行編輯。建議將的舊功能標記遷移到功能標記策略。爲此，可以先對舊式標誌進行截圖以進行跟蹤。然後通過API/UI刪除該標誌（無需更改代碼），並創建一個與已刪除的舊標誌同名的新功能標誌。另外，請確保策略和環境與已刪除的標誌匹配。

PowerShell作爲新註冊的Windows運行程序的默認選項

變更日期：2021年6月22日

在GitLab Runner 13.2中，PowerShell Core支持已添加到Shell執行程序中。在14.0中，pwsh它將是Windows上註冊的跑步者的默認外殼。Windows Command Shell仍可作爲Windows運行程序的選項使用。

從包中刪除/usr/lib/gitlab-runner符號鏈接

變更日期：2021年6月22日

在GitLab轉輪13.3，一個符號鏈接從加入/user/lib/gitlab-runner/gitlab-runner到/usr/bin/gitlab-runner。在14.0中，將刪除此符號鏈接，並將GitLab Runner安裝在中/usr/bin/gitlab-runner。

刪除FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL功能標誌

變更日期：2021年6月22日

在GitLab Runner 13.1，開始發送sigterm，然後再發送sigkill到Shell執行程序中的進程。還引入了一個新的功能標誌，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL它允許使用以前的過程終止方法。在GitLab Runner 14.0中，將刪除功能標記。

刪除Ubuntu 19.10（Eoan Ermine）軟件包

變更日期：2021年6月22日

Ubuntu 19.10（Eoan Ermine）已於2020年7月17日星期五到期，在GitLab Runner 14.0中，將從軟件包分發中刪除Ubuntu 19.10。

刪除非高峯時間模式以進行Docker Machine自動縮放

變更日期：2021年6月22日

在GitLab Runner 13.0，爲GitLab Docker Machine執行程序引入了新的配置設置計時選項。在GitLab Runner 14.0中，將刪除舊的配置選項非高峯時間模式。

刪除成功和失敗構建指標轉換

變更日期：2021年6月22日

在GitLab Runner 13.5中，介紹了failed並success聲明瞭一項工作。爲了支持Prometheus規則，選擇了to success和failure to finished作爲指標。在14.0中，將刪除轉換。有關更多詳細信息，

在自定義執行程序中刪除從step_script到build_script的翻譯

變更日期：2021年6月22日

在GitLab Runner 13.2中，將step_script to 的翻譯build_script添加到了自定義執行器。在14.0中，build_script舞臺將替換爲step_script。

升級更新

Omnibus版升級

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

yum updata/install gitlab-ce

就能自動完成升級：

docker安裝的實例

先停止和刪除舊的容器：

sudo docker stop gitlab

sudo 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 pull

docker-compose up -d

有關升級到GitLab 13.4的重要說明

在GitLab 13.0中，舊存儲已被棄用，舊存儲中的所有項目將自動升級到GitLab 13.2中的新哈希存儲。該遷移被延遲到GitLab 13.4。

升級到13.4後，仍在舊存儲中的所有項目都將通過後臺遷移自動遷移。