按照預期發版計劃，昨天GitLab官方發佈了又一個新的月度版本GitLab 13.5。該版本在通過協作和DevOps，讓開發團隊成員之間，各個工具之間進行協作。有關功能請追隨蟲蟲一起學習。

概述

移動應用程序安全性掃描

Gitlab安全掃描功能，可以幫助並賦予開發人員查找和修復安全漏洞的能力，但他們還希望iOS和Android移動應用程序具有相同的功能。根據集成指南，社區將 MobSF引入到合併請求管道和安全儀表板，以及SAST和所有其他GitLab安全掃描結果。

這種新的Mobile SAST語言覆蓋範圍和現有的對Swift和Java項目的模糊測試，現在爲移動應用程序提供了有價值的安全測試解決方案。

分組Wiki

分組可以通過多種方式進行協作，現在提供了更多協作方式。新版本可以在團隊級別上爲提供一箇中心協作點。隨之而來的是，會在側欄中找到更深層次的Wiki導航，以便於導航。

基於社區貢獻，現在可以直接從GitLab界面輕鬆啓動Gitpod Workspace。

在事件期間，可能很難從多線程討論中瞭解事件的順序。使用事件中討論的新時間線視圖，可以切換討論的時間線視圖。

代碼片段和模板有助於共享

代碼片段有助於組成員之間的代碼共享。單個代碼現在支持包含多個文件的代碼段，因此可以創建和共享由多個部分組成的複雜代碼段。

模板可促進跨團隊的最佳實踐和一致性。新版本中，將有將更多模板，例如新增加了模板，用於Terraform的新的GitLab CI/CD以及新的SAST配置UI，該爲沒有CI/CD經驗的用戶啓用GitLab CI/CD SAST模板。

跨工具協作

GitLab希望其他工具和諧集成。無論是獲取第三方安全掃描程序結果，還是與其他DevOps工具集成，都可以無縫集成展現。通過Generic Package Registry，可以在原始包中尚不支持的GitLab中存儲其他二進制類型，並將二進制包可以作爲發行附件，從而使發行和構建團隊可以在GitLab中有效地工作。

GitLab 13.5主要功能改進

組Wiki（PREMIUM及以上）

對於許多團隊而言，使用GitLab Wiki進行計劃和文檔編制是其工作流程的關鍵部分。儘管很受歡迎，但團隊仍在努力限制Wiki僅在項目級別可用的侷限性。從事多個項目的團隊需要爲每個存儲庫創建單獨的Wiki，從而帶來更好的體驗。

使用Omnibus GitLab安裝GitLab Kubernetes代理（PREMIUM及以上）

上個月，爲隨Helm安裝的自我管理的GitLab實例推出了GitLab Kubernetes代理。

新版本增加了對官方Linux軟件包的支持。在新的Kubernetes集成中，代理通過從GitLab提取新更改來協調部署，而不是GitLab將更新推送到集羣。

GitLab中查看集羣成本管理數據

許多用戶創建了自己的腳本，以更好地瞭解其集羣成本。但是，現在可以在GitLab用戶界面中查看羣集成本和資源使用情況的概述。該集成基於Kubecost的基礎上cost-model，用戶靈活地洞悉集羣的各個級別。使用提供的成本模板查看每月節點成本以及GitLab託管應用程序的成本，或者使用Kubecost提供的九種指標和GitLab的Prometheus查詢功能構建更復雜的自定義儀表板。

查看羣組時啓用實例級共享Runner

GitLab SaaS包括Linux和Windows運行程序，這些運行程序很容易使用，可以運行的GitLab CI/CD管道作業。某些組織要求其CI/CD作業只能在自建實例的運行程序上運行，因此，在每個項目上禁用實例級共享運行程序的使用會導致不必要的管理開銷。

新版本中，管理員可以在組級別啓用或禁用共享運行程序。管理員還可以允許組覆蓋全局設置，並在每個項目的基礎上使用共享運行器。

手動作業觸發下游或子管道

以前，不可能將觸發作業配置爲等待手動操作。這使得配置下游或子管道觸發器以等待用戶在運行之前單擊它們具有挑戰性。

在新版本中，增加了添加when: manual觸發作業的功能。使用該關鍵字使觸發作業等待，直到單擊''Play''按鈕。這樣可以更好地控制下游管道和子管道，使其僅在希望它們運行時才運行。

直接從GitLab啓動Gitpod工作區

工程師擁有複雜的開發環境，可能需要花費一些時間來設置和進行測試更改或探索具有挑戰性的新項目。一個項目的入門通常涉及以下文檔，安裝依賴項，並希望與運行的其他服務沒有衝突。此過程可能很耗時，容易出錯，並且可能無法準確地複製配置以測試項目併爲項目做出貢獻。

通過將Gitpod集成到GitLab中，可以直接從GitLab界面輕鬆啓動Gitpod工作區。在GitLab上編輯項目時，存在一個新的下拉選項可在GitPod中打開該項目：

Gitpod允許使用代碼定義項目的配置，因此可以一鍵啓動預構建的開發環境。這些環境是通過.gitpod.yml項目內部的文件配置的，其中包括Docker配置，啓動任務，編輯器擴展等選項。這種靈活的配置是項目代碼的一部分，使開發人員可以快速開始進行項目工作。

多個文件代碼段

工程師經常使用片段來共享代碼，可重用組件，日誌和其他項目的示例。這些有價值的信息通常需要其他上下文，並且可能需要多個文件。共享指向多個文件或多個片段的鏈接使用戶將這種上下文拼湊在一起並理解所呈現內容的範圍具有挑戰性。

在GitLab 13.0中，通過爲片段提供基於Git存儲庫的版本控制支持奠定了基礎。在查看代碼並理解其目的時，版本控制及其提供的歷史記錄是重要的上下文，但可能還不是全部。

GitLab現在在單個代碼段中支持多個文件，用戶可以創建由多個部分組成的代碼段。它將其用途擴展到無限的可能性。例如：

包含腳本及其輸出的代碼段。

包含HTML，CSS和JS代碼的摘要，可以輕鬆預覽結果。

包含docker-compose.yml文件及其關聯.env文件的代碼段。

一個gulpfile.js文件加上一個package.json文件，一起用於引導項目和管理其依賴項。

在單個代碼段中提供所有這些文件，爲可以共享的內容類型和查看它們時提供的上下文提供了更多選項。

通用軟件包註冊表

GitLab Package Registry產品中支持多種語言。但是，存儲尚不支持的其他二進制類型。

在GitLab 13.5中，可以將原始的程序包（就像在Nexus中一樣）添加到通用程序包註冊表中。展望未來，此功能有助於爲發佈資產創建基礎，並允許附加二進制包，從而使可以更輕鬆地使用GitLab打包和發佈軟件。

將二進制包附加到發佈

新版本中可以將二進制文件附加到的發行標籤gitlab.ci-yml。這擴展了對發行資產的支持，使其不僅包括資產鏈接或源代碼，還包括二進制文件。這使得開發團隊更容易採用GitLab並使用它來自動化發佈過程。

功能標記靈活的部署策略

使用策略時，粘性或體驗一致性僅由用戶ID決定，這可能是個限制；例如，匿名用戶不受到策略的影響。

通過使能夠基於會話ID，用戶ID或隨機（無粘性）定義粘性，新版本改進了推出策略。這使可以更好地控制部署，並支持匿名用戶。

功能標誌可用於所有層

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

目前已經正式完成將功能標誌移至Core供CE用戶免費使用。

部署到AWS EC2的模板

爲了幫助更有效地部署到AWS Elastic Cloud Compute（EC2），新增加了一個模板，展示如何入門。通過此模板，可以首先利用AWS CloudFormation API來配置自己的基礎架構。然後，將先前構建的工件推送到AWS S3存儲桶，並將內容部署到AWS EC2實例。

用戶可以在配置中包括模板，指定一些變量，他們的應用程序將立即部署並準備就緒。

新用戶註冊所需的批准

爲了在不損害安全性的情況下爲了減輕GitLab管理員的操作負擔，GitLab 13.5引入了新的實例級選項，要求任何新用戶帳戶都需要管理員的批准。默認情況下，此選項是禁用的，但啓用後，將需要實例管理員的手動批准，才能完成用戶註冊。

在新板上自動添加待辦事項和待辦事項清單

在大多數情況下，儘可能簡化工作流程將爲團隊提供最佳服務。爲了鼓勵這種情況，並使初次使用董事會的工作效率更高，更易上手，現在創建新的董事會將自動預先填充''待辦事項''和''待辦事項''列表，以便直接處理問題。

跨子組和項目同步迭代（STARTER及以上）

當前在組級別創建迭代，並且無法在子組或項目的上下文中查看迭代的報告。對於根據最小特權原則進行操作的組織而言，這是個問題。這也使大型組織難以使用相同的迭代節奏，同時也爲每個小組和項目提供了一種跟蹤其進度的方式。

爲了解決這個問題，現在迭代是沿組的層次結構繼承的，從而爲每個子組和項目提供查看查看範圍在其上下文中的迭代報告的功能。

此更改還使組織可以具有更大的靈活性，並可以控制他們要如何使用迭代。從頂級組配置迭代，以按照相同的時間表對齊所有組和項目，或者每個子組可以獨立管理自己的迭代節奏。

深度Wiki導航

在GitLab 13.5中，隨着組Wiki的發佈，在如何查看和導航Wiki的文件結構方面有了另一個巨大的改進。當前，如果有多個文件夾級別，則很難查看位置或瞭解Wiki的結構。這使導航，查找頁面和思維導圖變得困難。

在新版本中，在邊欄中引入了Wiki深層嵌套，因此可以查看所有頁面並進行相應導航。

將YouTube視頻嵌入到靜態網站編輯器中

GitLab 13.5在靜態站點編輯器的WYSIWYG模式下包括一個新的格式化選項，使只需單擊幾下即可輕鬆嵌入YouTube視頻。在模式窗口中輸入完整的嵌入URL或YouTube視頻ID後，靜態網站編輯器會在光標處插入正確的HTML塊，並在編輯器中顯示視頻的縮略圖。

不需要複製和粘貼格式正確的HTML即可將視頻嵌入Markdown文件中，並且知道所包含的視頻正確無誤，就可以放心地編輯文檔。Gitlab已經針對YouTube視頻嵌入對其進行了優化。

允許一維平行矩陣

以前，parallel: matrix以並行方式運行作業矩陣的關鍵字僅接受二維矩陣數組。如果要爲某些作業指定自己的值數組，這是有限制的。

在新版本中，具有更大的靈活性，可以以最適合的開發工作流程的方式運行作業。可以在一維數組中運行作業的並行矩陣，從而使管道配置更加簡單。這是實踐中的一個基本示例，它將針對不同版本的Node.js運行3個測試作業，但是可以將這種方法應用於特定的用例，並輕鬆地在管道中添加或刪除作業：

限制每個報告解析的單元測試數量

現在，可以從JUnit報告格式的文件中解析的測試數量受到限制，這些文件在一個構建中上載以供''測試摘要''和''單元測試''報告使用。對於GitLab在線倉，對於一個構建中的所有JUnit報告格式文件，最多可解析的測試數量爲500,000。

作業日誌中的預摺疊部分

作業日誌通常包含很長的部分，因此當掃描日誌以查找特定信息時，很難進行解析。

現在，可以將作業日誌部分設置爲默認摺疊。爲了使解析更加容易，只需[collapsed=true]根據需要在CI/CD配置文件中添加作業腳本即可。

使用API​驗證擴展的GitLab CI/CD配置

編寫和調試複雜的管道並不是一件容易的事。可以使用關鍵字來幫助減少管道配置文件的長度。但是，如果想事先通過API驗證整個管道，則必須分別驗證每個包含的配置文件，這既複雜又費時。

現在，可以通過API驗證管道配置的完全擴展版本，其中include包括所有配置。現在，調試大型配置變得更加容易和高效。

''程序包註冊表''頁面上的更多Conan接口信息

可以使用GitLab Conan存儲庫來發布和共享C和C++依賴項。當使用Package Registry用戶界面查找或驗證依賴項時，很難區分不同版本的依賴項。用戶界面顯示了名稱和版本，但不包含conan_user或conan_channel。這兩種方法通常用於區分不同的程序包。例如，以下配方將在用戶界面中顯示爲Hello version 1.0。

Hello/1.0@trizzi/stable

Hello/1.0@trizzi/beta

Hello/1.0@other_user/stable

現在，所有路徑都顯示在用戶界面中，從而使查找和驗證所需包裝變得更加容易。

配置選項支持將部署密鑰推送到受保護的分支

在版本12.0中，更新了部署密鑰，以便具有寫訪問權的密鑰不再能夠將提交推送到受保護的分支。作爲此限制的解決方法，一些用戶刪除了對master分支的訪問限制，使其不受保護，並允許所有開發人員推送到master。

這會增加安全風險，因此爲了提供更好的選擇，Gitlab決定通過配置設置重新啓用以前的行爲。

啓用gitlab-pages守護程序發送預壓縮的br文件

爲了改善GitLab頁面加載時間，新增加了對Brotli壓縮文件的支持。這有助於降低每頁所需的帶寬，從而縮短站點加載時間。

與API中的項目版本相關聯的支持組裏程碑（PREMIUM及以上）

對於GitLab中跨多個項目工作的發佈經理，通常使用組裏程碑來收集計劃發佈的相關項目，GitLab版本可以與項目里程碑相關聯，新版中可以通過Releases API將組裏程碑與項目版本相關聯。

GitLab託管集羣的可自定義名稱空間

GitLab託管集羣的用戶現在可以在創建集羣時選擇在每個項目中使用單個名稱空間，或在每個環境中使用單個名稱空間。每個項目使用單個名稱空間可以簡化查找審閱應用程序的過程，而每個環境使用單獨的名稱空間可以提供額外的安全性。

查看Kubernetes代理商列表（PREMIUM及以上）

GitLab現在通過在GitLab用戶界面中顯示代理及其配置來幫助管理Kubernetes代理。計劃在將來的發行版中爲代理提供更多管理工具。

有關事件討論的時間線視圖（PREMIUM及以上）

manbetx客戶端打不開評論和線索是在事件上進行協作的好方法，但是如何才能從線索化討論中按時間順序理解發生的一切？

新版中可以將討論視爲評論時間表，以幫助團隊瞭解在戰鬥中發生的事件的順序，並進行有效的事後評估。

刪除價值流（PREMIUM及以上）

在GitLab 13.3中，通過將每個組的多個價值流引入了Value Stream Analytics。現在，可以刪除在組中創建的任何自定義值流。

合併請求分析過濾器控件（STARTER及以上）

在GitLab 13.3中，引入了合併請求分析功能，可幫助更有效地評估合併請求吞吐量的效率和生產力。

GitLab 13.5引入了過濾器控件以合併請求分析。這可幫助根據篩選條件（例如，接受人，作者，標籤，里程碑或分支）在合併請求分析中優化數據範圍。

添加需求描述（ULTIMATE）

如果可以在工具中添加其他詳細信息，例如驗證標準，驗收標準和基本原理，則需求管理可以提高生產率。

GitLab需求管理現在支持用戶添加詳細信息和內容，以在啓用了GitLab Markdown的每個需求的描述字段中簡化對需求的管理。

一鍵刪除問題標籤

從過去需要單擊三次的才能刪除問題中標籤：從服務器中獲取標籤的新列表，然後使用搜索框找到要刪除的標籤。考慮到GitLab用戶每天大約要刪除55,000次問題，因此這是不直觀且效率低下的。新版本中可以單擊一下刪除問題的標籤。

分支的訪問控制將覆蓋代碼所有者的要求（PREMIUM及以上）

合併請求批准限制了將代碼推送到受保護分支的方式。這對於提高代碼質量和實施合規性控制很有幫助。要求特定分支的代碼所有者批准很有用，以防止未經代碼所有者批准而直接更改文件。但是，它缺乏靈活性，無法自動使用默認分支上的更新標籤，版本或部署跟蹤器等用例。

先版本中，可在分支保護設置中將用戶或組指定爲''允許推送''，則他們可以直接推送到爲代碼所有者批准而配置的受保護分支。因爲分支保護設置是GitLab項目的主要訪問控制機制，所以此設置現在優先於''代碼所有者''設置。

從靜態站點編輯器編輯合併請求描述

工程最佳實踐鼓勵包括簡潔的標題和說明以及對文件所做的任何更改。所提供的上下文在審覈過程中以及用於記錄更改的理由或動機非常有價值。

靜態站點編輯器儘可能從編輯器中抽象出盡可能多的Git工作流。一種方法是使用默認的分支名稱，合併請求標題和描述。這樣就可以進行簡單的一鍵提交，但是生成的合併請求缺少該關鍵上下文。

在GitLab 13.5中，現在可以在更改中包括一個可選的標題和描述，以填充更具描述性和實用性的合併請求。

單擊即可將合併請求標記爲''草稿''

即使沒有準備好合並代碼，創建合併請求也是與他人共享文稿並開始對話的好方法。爲了向其他人發出信號，表示還沒有準備好對文稿進行審查或合併，可以在合併請求標題前加上draft（以前稱爲wip）。這很有用，但是需要進入編輯模式，導航到合併請求標題，然後鍵入所需的前綴。

爲了更快地使用此功能，在合併請求頁面的右上角直接引入了''標記爲草稿''和''標記爲就緒''按鈕（而無需編輯其描述即可更改）。只需單擊一下，就可以表明工作正在進行中，尚未準備好進行合併，反之亦然。

PostgreSQL 12可用性

GitLab 13.3中，啓動了與PostgreSQL 12的初始兼容性，並且可以在自建GitLab實例中可選啓動。

GitLab 13.5中，已經完全支持PostgreSQL 12，包括在具有Geo和PostgreSQL集羣的部署中。要在羣集中使用PostgreSQL 12，必須使用Patroni進行復制和故障轉移。PostgreSQL 12不支持使用repmgr進行復制和故障轉移。

PostgreSQL 12將成爲13.6中新安裝的GitLab的默認版本。對於現有GitLab部署的升級，它將成爲13.7中的默認版本，並可以選擇退出並保留在PostgreSQL 11上。

可選緩存失敗的管道

當管道獲取大量外部依賴項（例如NPM）時，如果無法選擇對失敗的管道上的依賴項進行高速緩存。新版本中可以選擇保存緩存，而不管作業狀態如何，這可以在失敗的管道上進行迭代時節省時間和資源。

僅在作業/管道成功時才進行緩存仍然是默認設置。這可以防止未清除的不完整依賴項緩存導致後續管道失敗。新版本中可以設置何時總是安全地啓用緩存，支持增量構建並幫助加快到達第一個綠色管道的過程。

允許更輕鬆地從告警頁面回滾

當收到部署觸發的告警時，由於告警缺少其他上下文，因此很難立即瞭解發生了什麼。

在新版中，現在可以單擊直接鏈接以快速導航到相關環境並獲取所需的上下文。這樣可以更輕鬆地瞭解需要注意的環境。在環境頁面中，如果需要，還可以輕鬆查看相關部署並回滾到以前的部署。

服務水平協議倒數計時器（PREMIUM及以上）

服務水平協議（SLA）對於客戶而言至關重要。違反SLA可能會增加收入，並降低客戶滿意度和信心，但是要監視SLA的多個活動事件則具有挑戰性。SLA倒數計時器使用戶可以配置特定的SLA，並在事件上顯示SLA倒數，以幫助確保滿足SLA並使客戶滿意。

查看告警集成列表

運營團隊管理集成到其中央事件管理平臺中的許多告警工具。當配置界面，身份驗證密鑰和重要URL位於不同位置時，管理和維護這些工具和集成非常複雜且令人困惑。

新版中，GitLab項目在設置>操作>告警中爲團隊提供了一個列表，用於查看和修改告警配置。

Omnibus的改進

爲Patroni添加了附加功能，Patroni是Omnibus中用於PostgreSQL複製和故障轉移的新解決方案。使用newrestart和reloadsub命令，可以重新啓動Patroni或在領導者數據庫節點上重新加載Patroni配置，而無需觸發自動故障轉移。revert-pg-upgrade現在支持該命令以還原由Patroni管理的集羣的PostgreSQL升級。

現在，可以使用SSL證書對PostgreSQL數據庫進行客戶端身份驗證，以代替使用密碼。該功能將需要自己的SSL證書管理解決方案才能使用此功能。

GitLab 13.5包含了Mattermost 5.27，它是開源的Slack替代產品。最新版本包括可輕鬆安裝和維護Mattermost的Mattermost Omnibus（Beta），以及安全更新。

Gitlab Runner 13.5

同期還發布了GitLab Runner 13.5。GitLab Runner和GitLab CI/CD協同工作，GitLab CI/CD是GitLab附帶的開源持續集成服務。新增功能：

允許用戶設置kubernetes本地臨時存儲請求和限制；

提供Docker鏡像以在Google Compute虛擬機上自動安裝GitLab Runner

引入變量以指示當前構建狀態；

將標籤添加到由GitLab Runner創建的Docker緩存卷；

Windows上bash作爲shell程序使用的Runner通過反斜槓而不是正斜槓傳入路徑/。

Bug修復

修復Debian的存儲庫爲arm64提供32位ARM二進制文件的bug。

更多內容請參考GitLab Runner變更文檔。

安全和合規性審計

自定義SAST和祕密檢測規則（ULTIMATE）

GitLab靜態應用程序安全測試（SAST）和密碼檢測現在支持自定義檢測規則。這允許GitLab用戶更改漏洞檢測默認設置，以根據組織的喜好調整結果。SAST自定義規則集允許排除規則並修改現有規則的行爲。密碼檢測支持禁用現有規則並添加新的正則表達式模式，以允許檢測任何類型的自定義祕密。

可以通過將新文件添加到.gitlab名爲sast-ruleset.toml或secret-detection-ruleset.toml包含以正確符號表示的自定義的文件夾中來定義自定義規則集。可以瞭解有關此文件格式的更多信息，並官方SAST自定義規則集和Secret Detection自定義規則集的文檔中查看示例。

提供對頂級組的最小訪問權限（PREMIUM及以上）

爲了幫助組織使用具有更細粒度訪問控制的SAML SSO，組所有者可以爲用戶分配最小的訪問角色。具有最小訪問權限的用戶可以在UI中以及通過API列出組。但是，無法瀏覽資源，項目和子分組等詳細信息。可以在供應時爲SSO/SCIM將此角色設置爲默認角色，或者將其分配給頂級組中的現有用戶。

對iOS和Android移動應用程序的SAST支持

GitLab SAST現在支持移動應用程序，包括用Objective-C和Swift編寫的iOS應用程序，以及由移動安全框架（MobSF）支持的用Java和Kotlin編寫的Android應用程序。最初，該分析儀支持源代碼分析，打算在將來擴展對.ipa和.apk文件的二進制掃描的支持。

憑據選項卡''SSH''證書列表增加刪除按鈕（ULTIMATE）

管理名稱空間包括確保知道誰有權訪問以及如何訪問。爲了提高SSH密鑰的安全性，應該能夠在適當的時候刪除用戶的SSH密鑰。爲了支持此控件，新添加了一個刪除按鈕，供自我管理的管理員根據需要刪除這些密鑰。

現在，可以從證書列表管理用戶的SSH密鑰。

審覈事件捕獲失敗的兩因素身份驗證登錄（PREMIUM及以上）

GitLab名稱空間的完全可追溯性和可審覈性對於成功的安全合規性計劃至關重要。重要的是要知道兩因素身份驗證嘗試何時失敗，因爲這表明用戶或惡意行爲者知道帳戶密碼，但無權訪問第二因素設備。

現在，在GitLab 13.5中，可以評估失敗的兩因素身份驗證嘗試的次數，以幫助做出決定。可以在實例級別的''審覈事件''表中找到失敗的兩因素身份驗證嘗試。在將來的迭代中將提供對組級別的支持。

改進的安全掃描合併請求體驗

現在所有用戶都可以使用SAST和Secret Detection，Gitlab改善了所有GitLab用戶在合併請求中與安全掃描結果進行交互的體驗，從而使任何人都可以更輕鬆地訪問安全掃描結果。以前的安全掃描結果只能在''管道概述''頁面上訪問，用戶必須知道在哪裏可以找到它們。

現在，所有合併請求將顯示是否已運行安全掃描並幫助用戶找到作業工件。計劃在接下來的幾個版本中繼續改善這種體驗。此更改不會更改Ultimate用戶的MR體驗。

更新nodejs-scan SAST分析器以使用njsscan v0.1.5

新版中更新了Node.js SAST分析器，其中添加了100多個新的檢測規則。這個版本也改變檢測規則，由njsscan v0.1.5的和semgrep支持，在新SAST自定義規則集。

針對C/C ++和NodeJS漏洞的改進的SAST嚴重性數據

當可從安全掃描分析儀獲得時，GitLab靜態應用程序安全測試將提供已識別漏洞的嚴重性數據。最近更新了NodeJS（nodejsscan）和C/C++（flawfinder）的分析器，以增加對嚴重性數據的支持。該數據將有助於增加安全批准規則的可用性和準確性，因爲更少的漏洞將報告''嚴重''。將來，將增加其他分析器缺少漏洞元數據的功能，並添加一種機制，以允許自定義漏洞元數據，使組織能夠定製結果以匹配其風險狀況。

SAST配置用戶界面的改進（ULTIMATE）

該GitLab SAST配置UI工具已經擴展到支持更多的設置選項，現在可以更新現有GitLab CI/CD文件簡單。這種配置經驗使非CI/CD專家可以更輕鬆地開始使用GitLab SAST。該工具可幫助用戶創建合併請求以啓用SAST掃描，同時利用最佳配置實踐（例如使用GitLab管理的SAST.gitlab-ci.yml模板和正確覆蓋模板的設置）。

配置UI現在支持特定SAST分析器設置的配置，允許組織根據自己的安全偏好來定製SAST結果。現在，配置用戶界面還可以更新現有的簡單.gitlab-ci.yml文件，從而允許該工具與已經安裝了GitLab CI/CD的項目一起使用。在即將發佈的GitLab版本中，還將向GitLab Core用戶擴展對該工具的訪問。

GitLab Helm chart改進

已添加''任務運行器'' chart的文檔。Task Runner用於執行管理任務，例如rake任務和備份。新文檔說明了可以爲Task Runner配置的設置，並提供了使用示例。

Geo複製外部合併請求差異和Terraform狀態文件

Geo現在支持將外部合併請求差異和Terraform狀態文件複製到輔助節點，從而允許分佈式團隊從最近的Geo節點訪問它們，從而減少了延遲並改善了整體用戶體驗。此外，在故障轉移到該輔助節點時，還可以從輔助節點還原該數據。

在使用情況頁面上跟蹤Pipeline Artifact存儲

在最初發布PipelineArtifacts之後，存在一種使用存儲的工件，但未在''存儲使用配額''頁面上進行跟蹤。這意味着無法準確表示實際有多少可用存儲空間。

現在Job和PipelineArtifacts都由Artifacts標籤表示，因此可以確切知道Artifacts佔用了多少存儲空間。

容器註冊表清理策略的重大改進

對標籤使用清除策略從容器註冊表中刪除不需要的標籤時，可能已經注意到，並非總是像期望的那樣刪除標籤。結果，很可能必須手動使用GitLab API進行干預才能批量刪除註冊表標籤，或者忽略了該問題，從而增加了存儲成本。

此外，可能會遇到策略在其中運行但僅部分完成的問題。當策略嘗試刪除許多鏡像而超時時，會發生這種情況。如果發生這種情況，它將在策略的下一次計劃運行中繼續刪除標記。繼續前進，將看到一條警告，表明尚有部分運行的策略。這樣，可以決定是否要手動進行干預。

使用新標籤上的鏡像摘要創建發佈

Docker支持不可變的鏡像標識符，採用了這種最佳實踐來更新雲部署鏡像。標記新鏡像時，還以編程方式在構建鏡像摘要時對其進行檢索，並創建發行說明以將該摘要有效地傳達給用戶。這樣可以保證服務的每個實例都運行完全相同的代碼。可以回滾到鏡像的早期版本，即使該版本未標記（或不再標記）。如果在部署過程中推送新鏡像，這甚至可以防止出現競爭情況。

通過AutoDevOps進行增量部署與Kubernetes 1.16兼容

GKE中的集羣已於2020年10月6日自動升級到Kubernetes v1.16。新更新了Auto DevOps，以支持此版本的增量部署以繼續按預期工作。此升級影響使用定時增量部署連續部署到生產的用戶，以及自動部署到登臺但手動部署到生產的用戶。

將Auto DevOps升級到Helm 3

Auto DevOps旨在立即爲用戶帶來出色的易用性和安全性最佳實踐。到目前爲止，Kubernetes環境中的Auto DevOps要求在羣集上安裝Helm v2。考慮到蒂勒的根訪問權限，這帶來了安全風險。隨着Helm v3的推出，不再需要Tiller。

當前的GitLab版本最終支持Helm v3，因此可以放心，將獲得最新的出色功能和安全更新。對於GitLab託管羣集，可以按照官方文檔升級Helm安裝。請注意，Helm 2支持預計將在2020年11月左右結束。

使用GitLab和Terraform快速入門

新的GitLab CI/CD模板使無需任何人工即可設置Terraform管道，從而降低了團隊採用Terraform的進入門檻。

Bug修復

GitLab 13.5中一些值得注意的錯誤修復有：

擴展版本的NuGet軟件包無法上傳的問題；

容器註冊表清理策略策略不會刪除鏡像的問題；

報告者級別不足以瀏覽軟件包列表；

組級別的部署令牌在Maven組終結點上失敗；

Go get 對於深層嵌套項目失敗，並顯示500錯誤；

軟件包名稱包含句點時，無法安裝Python軟件包；

存在舊版PostgreSQL實例時，Auto Deploy遇到錯誤；

''新/編輯版本和新片段''頁面上的''預覽更改''不起作用；

最新版本v0.4.0之後未更新最新的docker標籤；

威脅監控策略編輯器的各種UI修復；

''隱藏隱藏''切換在管道安全儀表板中不起作用；

從漏洞創建問題會生成空問題；

SAST Spotbug設置SAST_JAVA_VERSION：11不起作用；

具有自定義CA的SAST eslint無法編寫gitconfig；

允許通過Git使用項目訪問令牌；

對於需要接受服務條款的實例，允許使用Project Access令牌；

刪除令牌後刪除項目訪問令牌用戶；

史詩篩選器不適用於開始日期或截止日期排序；

'' Epic！=''的問題搜索不起作用；

搜索將返回未排序的結果，以查找渴望加載的範圍；

代碼搜索未在搜索結果中標識正確的代碼blob；

搜索結果中的代碼鏈接應使用默認分支名稱而不是提交哈希；

GEO：修復了存儲移動後項目/設計/Wiki存儲庫無法重新同步的問題；

GEO：修正Wiki/設計，而在主要站點上沒有存儲庫的嘗試一次又一次地同步

GEO：修復程序包文件視圖默認情況下不起作用；

性能改進

在每個版本中，將繼續在改善GitLab性能方面取得重大進展。Gitlab致力於提高每個GitLab實例的速度。在GitLab 13.5的性能改進工作集中於請求zip文件時的Cache dataOffset和symlink。

功能變更

默認的瀏覽器性能測試作業將在GitLab 14.0中重命名

變更日期：2021年5月22日

目前瀏覽器性能測試在默認performance情況下的作業中運行。隨着GitLab 13.2中的負載性能測試的引入，該命名可能會造成混淆。爲了搶到測試是在瀏覽器性能測試，GitLab 14.0模板中默認作業名稱修改爲browser_performance。

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

變更日期： 2021年1月22日

目前GitLab支持的日誌格式：

對應用程序日誌的文本，JSON和logstash日誌格式。

對訪問日誌的文本，JSON和組合日誌格式。

Gitlab 將刪除logstash和組合格式，只支持使用兩個選項文本和JSON統一所有應用程序和訪問日誌的格式。

刪除Container Registry日誌hook

刪除日期： 2021年1月22日

容器註冊表當前支持只能用於電子郵件通知的日誌記錄hook。基於日誌條目的告警通常由單獨的工具處理。據所知，GitLab用戶都沒有依賴此功能，並未使用它。該功能的實現與底層的日誌記錄庫緊密耦合，這會對影響可用功能切換時的依賴關係。爲了簡化註冊表功能和配置，將刪除對日誌記錄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代理透傳緩存

根據對GitLab管理員進行調查後，Gitlab決定將不會刪除該功能。

本proxy部分允許將Container Registry設置爲上游存儲庫的本地鏡像。

Container Registry刪除對Bugsnag的支持

刪除日期： 2021年1月22日

Bugsnag是容器註冊表支持的錯誤報告服務之一，目前沒有用戶依賴此服務。 GitLab推薦使用。爲了簡化和合並受支持的錯誤報告服務，打算增加對支持，並刪除對Bugsnag的支持。

Container Registry刪除對NewRelic的支持

刪除日期： 2021年1月22日

NewRelic是容器註冊表支持的錯誤報告服務之一，目前沒有用戶依賴此服務。 GitLab推薦使用。爲了簡化和整合支持的錯誤報告服務，打算添加對Sentry的支持，並刪除對NewRelic的支持。

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

刪除日期： 2021年1月22日

GitLab將於2021年1月22日停止Docker註冊表v1 API拉取功能.Docker在2019年6月停止對該功能的支持了，該功能使GitLab團隊可以專注於爲提供更多價值並針對當前註冊表用例的功能和修補程序。

通過完成以下步驟，GitLab上的v1註冊表API的現有用戶可以移至v2註冊表API：

將Docker Engine更新到17.12或更高版本，以便與v2註冊表API兼容。

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

停止對CentOS 6的支持

變更日期： 2020年11月22日

CentOS 6將於2020年11月到期。GitLab13.6將是在CentOS 6上部署GitLab的最後一個受支持的版本。建議升級到CentOS 7或8。

計劃棄用的GraphQL字段將在13.6中永久刪除

變更日期： 2020年11月22日

按照GraphQL棄用過程，在12.x中棄用的以下字段將在13.6中永久刪除：

Types::CommitType - :latest_pipeline

Types::GrafanaIntegrationType - :token

Types::IssueType

Types::EpicIssueType - :designs

Types::MergeRequestType - :merge_commit_message

Types::TimelogType - :date

升級更新

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.5的重要說明

已發現有些實例可能會受影響，這些實例的升級到13.5.0後，會有assertion錯誤。官方正在努力立即發佈13.5.1以解決此問題。

在此期間，可以採用一種簡單的解決方法：

chmod 02770 /var/opt/gitlab/git-data/repositories

Workhorse套接字的默認路徑從中的更改/var/opt/gitlab/workhorse/socket爲/var/opt/gitlab/workhorse/sockets/socket13.5。gitlab-ctl reconfigure升級期間需要A來應用此更改。如果使用SELinux並指定了自定義套接字路徑