GitLab 13.4發布，安全中心和K8S代理等

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

概述

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

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

降低風險的另一種方法是使用新的GitLab Kubernetes代理。運營商可以從GitLab部署到其Kubernetes群集，而無需將其群集打開到整個網絡。GitLab託管Terraform狀態的新Terraform狀態文件引入自動版本控制支持，以支持合規性和調試需求。最後但並非最不重要的一點是，&34;儀錶板已演變為具有漏洞報告和設置功能的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導出和問題委員會重點模式。這僅適用於&34;關係。&34;和&34;保留在付費層中。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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軟體包的作用域限定為一個項目，從而可以輕鬆發布和共享項目的依賴項。

在合併請求中設置&34;時的通知

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

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

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

將事件創建為問題類型

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

Markdown中的參考GitLab告警

在GitLab風格的Markdown中添加了特定於告警的參考，從而改進了告警，使可以輕鬆共享和參考告警。用於^alert34;告警詳細信息&34;設置&34;需求&34;測試報告&34;事件詳細信息&34;安全性和合規性&34;威脅管理&34;策略&34;安裝&34;安全儀錶板&34;漏洞報告&34;設置&34;設置&34;漏洞管理&34;合規性儀錶板&34;嚴重&34;高&34;未知&34;掃描程序配置文件&34;蜘蛛超時&34;掃描儀配置文件&34;詢問社區&34;設置&34;通知&34;不推薦使用的作業系統"頁面以獲取更多信息。

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

變更日期：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 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

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

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

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