按照慣例，昨天GitLab釋出了有一個新版本13.9。該版本在DevSecOps做了大量的增強，安全警報儀表板可對高優先順序警報進行分類，維護模式可保證對分散式團隊的更好的維護，還有在可視性方面的增強，包括對DORA指標的額外支援， 以及提出了新的口號，讓使用者可以實現“更好、更快的產品！”。詳細的功能請追隨蟲蟲一起學習。
概述確保生產環境的安全和可用性是當務之急，但是很難平衡。新安全告警儀表板可以區分需要立即阻止的可疑網路活動或僅需要進一步關注的可疑網路活動，從而幫助使用者平衡安全性和可靠性，從而最大程度地減少對使用者的干擾。在模糊測試覆蓋率指數新增JavaScript和Python支援，從而更輕鬆地構建安全可靠的軟體，並將結果傳送到Security Dashboard中。
GitLab立足於服務分散式團隊，新的維護模式可在執行更多管理任務時實現例項的只讀可用性，從而進一步減少停機時間。可變的Gitaly複製因子改善了資料儲存的可擴充套件性和冗餘性，使用者可以將群集調整到自己的儲存和預算約束，同時還可以進行水平擴充套件。
可見性是擴充套件DevOps的另一個核心要求，並且組級別的Release Analytics（分析）繼續增加了對DORA指標的支援，而DORA指標現已彙總到組中的專案中。該單元測試報告新的失敗測試計數器和一個新的合併請求數指標，平均時間合併。
對於DevOps的新手，或者是更新了停滯不前的工作，那麼發出“更快提供更好的產品”的命令聽起來就像是“事半功倍”。這可能會違反直覺。但是，DevOps是答案，而自動化是實現兩者的關鍵。
確保構建和測試更快的一種可靠方法是尋找配置中的冗餘。13.9中的新功能透過啟用重用CI/CD配置的管道來從任何作業中節省時間。
大規模自動化通常需要減輕複雜性。將管道配置分解為許多檔案後，可以檢視該配置的擴充套件版本。新版本中使用父子或多專案管道的部署過程還可以使用資源組來管理跨階段，作業甚至專案的併發。
GitLab 13.9中主要功能改進維護模式（PREMIUM及以上）系統管理員有時會在GitLab例項上執行維護操作，以使其保持最佳效能。管理員希望在進行這些操作時為其使用者提供最高級別的訪問許可權。例如，實現輔助站點執行故障轉移測試，作為公司業務連續性計劃的一部分。在故障轉移之前，需要暫停更改一小段時間，以確保輔助節點完全同步。在GitLab 13.8之前，只能透過限制使用者登入來說實現，但是這會阻塞整個UI，並使使用者無法訪問GitLab。
GitLab 13.9新增加維護模式，可以在應用程式級別禁用寫操作。該模式下，GitLab對於所有非管理員使用者實際上都處於只讀狀態（管理員仍然能夠編輯應用程式設定，並且後臺作業可以繼續）。普通使用者可以登入到GitLab，檢視介面並執行其他只讀操作，例如git clone或git pull。使用維護模式，系統管理員可以執行維護操作，例如故障轉移到輔助站點，而對常規使用者的干擾最小。
目前，GitLab已經支援零停機時間更新，並且不需要啟用維護模式即可使例項保持最新。
組級別釋出Analytics（ULTIMATE）在GitLab 13.9中，可以檢視組級別的釋出分析。為使用者提供了與該組關聯的每個專案的所有發行指標的彙總檢視。可以檢視屬於該組的發行版以及與發行版關聯的專案百分比。此功能還可以作為在組級別支援DORA 4指標的第一個迭代。
覆蓋特定儲存庫的Gitaly Cluster複製因子（PREMIUM及以上）之前Gitaly群集的複製因子是群集中的節點數。這使得無法為儲存需求非常大的GitLab例項啟用Gitaly Cluster。例如，具有50個節點的500 TB群集將需要配置25 PB的儲存空間。為了使Gitaly Cluster可用於具有大量儲存需求的例項，需要一種方法來指定一個複製因子，該因子應小於叢集中節點的總數。
在GitLab 13.9中，可以將每個儲存庫的複製因子分別設定為小於叢集中節點數量的任何數量。這僅允許複製最重要或活動的儲存庫，而將其他不太重要的儲存庫保留在較少數量的節點上。這將使組織能夠根據自己的儲存和預算限制調整群集。GitLab啟用了一種為所有新建立的儲存庫配置預設複製因子的方法，這為使用者提供橫向擴充套件其Gitaly群集的必要手段。
在單元測試報告中輕鬆檢視重複失敗的測試在檢查管道中的失敗測試時，很難判斷失敗測試是否是需要調查的合法失敗，還是需要透過下一次執行的不穩定測試。
重複失敗測試計數器的下一次迭代將重複失敗測試計數器新增到單元測試報告中。新版本中，可以看到測試在預設分支上失敗的頻率，而無需與測試執行相關聯的合併請求。
從任何作業中選擇性引用CI/CD配置在多個作業中重用相同的配置，有兩個選擇：新增YAML定位符（不能在不同的配置檔案中使用）或使用extends重用整個配置。
在13.9中，添加了一個名為的新YAML函式!reference，該函式使使用者將需要重用的部分配置以標籤的形式在主配置檔案引用使其成為CI/CD管道的一部分。
檢視CI/CD配置的擴充套件版本在配置管道時，可以像include和extends經常使用關鍵字。這些關鍵字有助於將一個較長的管道配置檔案分解為多個檔案，從而提高了可讀性並減少了重複。不幸的是，這些關鍵字會使管道配置難以遵循。在某些配置中，管道配置檔案主要由其他包含的配置檔案的列表組成。
在新版本中，可以檢視管道配置的版本，並將所有include和extends配置合併在一起。這樣，更容易理解較複雜的管道流程並簡化了除錯過程。
多專案和父子管道的資源組新版本中，可以使用資源組，如果部署過程中使用子管道或者多專案管道。管道可能會包含多個階段，多個工作，甚至有可能跨專案。資源組可確保一次僅執行一個下游部署管道，因此可以安全地進行部署。之前，resource_group僅支援同一專案中的部署作業。
關注使用者活動GitLab使用者現在可以關注其他使用者在GitLab中的活動。關注使用者可以幫助保持團隊夥伴和關鍵專案貢獻者的活動最新狀態。可以在其他使用者個人資料中關注或取消關注其他使用者。要檢視其活動，請轉到頂級“活動”檢視，然後選擇“關注的使用者”選項卡。
功能標記的Markdown連結13.9中增加了功能標記Markdown連結。使用者可以使用[feature_flag:<IID>]在討論或評論中提及以引用特定功能標記。單擊生成的連結以轉到該功能標記的編輯頁面。這樣讓功能標記上協作變得更加輕鬆和便捷。
要求稽核者進行後續稽核合併請求作者收到審閱者的反饋。通常，需要重新稽核此反饋，以確保所有問題均已得到適當解決。作為釋出作者，需要與審稿人溝通對後續工作的需求。
對於已經審閱過合併請求的審閱者，新版本中可以請求重新審閱。此請求會觸發一個待辦事項和電子郵件通知，以提醒使用者需要對自己的commit進行後續稽核。
Jira Cloud應用程式的改進現在，可以使用Atlassian Marketplace上的GitLab for Jira Cloud應用程式，將Jira Cloud專案資料與GitLab同步。該外掛在“ Jira開發面板”中顯示有關分支，提交，合併請求，部署和功能標誌的資訊。使用它可以檢視正在進行的工作的當前狀態，然後快速導航回到GitLab內部的那些頁面。
為了使這些功能更易於使用，在過去的幾個里程碑中，對初始設定過程進行了重大改進，現在連線GitLab名稱空間比以往任何時候都容易。只需在Atlassian Marketplace上檢查。
改善SAML超時體驗（PREMIUM及以上）當用戶的GitLab組的SAML會話達到7天超時限制時，該使用者將不再需要單擊確認頁面來續訂他們的會話。manbetx客戶端打不開會自動聯絡組的身份提供商以檢查有效的會話並根據需要擴充套件它。此更改改善了組成員的體驗，併為將來減少SAML會話超時打開了大門。
透過API管理專案訪問令牌在GitLab 13.9中，新引入了一個API來管理專案訪問令牌。用於專案訪問令牌的API Access對希望控制外部系統中或透過自定義自動化的專案訪問令牌供應的使用者啟用整合。
出現使用者忙碌狀態和MR側欄在上一個版本中，添加了一個“使用者忙碌”指示器，以指示協作夥伴是否可用於程式碼審查和其他任務。在13.9中中，在在釋出和合並請求側欄的“受讓人”部分也顯示了 “使用者忙碌”指示器。
從13.9開始，在使用者活動頁面和使用者個人資料中可以檢視所有Epic活動，並使用它來跟蹤Epic協作。
VS Code中的GitLab CI變數自動補全GitLab CI是快速且可高度配置的，但是要記住所有預定義的環境變數很難，並且錯誤的關鍵字字可能會導致.gitlab-ci.yml配置實效。為了簡化配置GitLab CI管道的過程，GitLab工作流程的3.11.0版本在編輯.gitlab-ci.yml檔案時為預定義的環境變數提供了自動補全功能。
自動補全對話方塊中的工具提示提供了有關變數用途的資訊以及支援的GitLab和Runner版本。這些額外的資訊確實有助於確保使用者CI配置有效。
將變化標記為在合併請求中檢視在檢視更改許多檔案的合併請求時，要跟蹤已檢視的檔案是一項挑戰。當需要重新審閱或花費更多時間重新獲取合併請求中每個檔案的上下文時，審閱效率非常低。
13.9中，可以在合併請求中將檔案標記為“已檢視（Viewed）”，以幫助通知使用者檔案已被稽核。此更改使審閱者可以快速跟上他們審閱的內容以及對於合併請求仍需要審閱的內容。
檢視VS Code中的程式碼審閱註釋在GitLab Workflow for VS Code的先前版本中，可以檢視VS Code中的合併請求更改。但是，檢視合併請求提出的更改只是檢視該更改並能夠響應反饋的一部分。
組碼覆蓋率資料圖（PREMIUM及以上）以前釋出的組程式碼覆蓋率資料是檢視組中專案當前測試覆蓋率以及獲取原始資料以在GitLab外部進行視覺化的一種簡便方法。現在，組程式碼覆蓋率資料包括一個組的所有專案的平均覆蓋率的圖表，因此可以一目瞭然地看到該組的測試覆蓋率隨時間變化的趨勢。
例項配置以控制最新的工件儲存在上一版本中，希望透過新增專案設定以禁用保留最新工件來改善儲存消耗管理。自建例項的使用者可能希望選擇退出整個例項，因此新添加了一鍵式選項，以禁用為所有專案保留最新的工件。
CI/CD儀表板選項卡的專用URL（ULTIMATE）在13.8中，在CI/CD Analytics下增加了對部署頻率圖表的支援。在新版本中，透過為每個選項卡引入URL來新增直接導航到每個CI/CD分析圖表的功能，從而可以輕鬆地將此頁面新增為書籤或傳送給其他同事以進行檢視。
Kubernetes部署支援頁面訪問控制在GitLab 13.8中，引入了對GitLab Pages的初始支援，可以透過Kubernetes部署GitLab，使使用者可以輕鬆地部署靜態網站。
在13.9中，新增加了Pages 的訪問控制，可以選擇將頁面站點的訪問許可權限制為專案成員。GitLab Helm圖表中支援pages所有功能。
子組的組Webhooks（PREMIUM及以上）GitLab使您更容易使用子組Webhook構建子組管理自動化。建立或刪除子組時將觸發此Webhook。現在可以在不依賴連續API呼叫的情況下構建自動化，這很麻煩並且會給您的GitLab例項帶來不必要的效能負載。
改善了專案成員列表的使用者體驗新版版中對專案成員列表進行了重新設計，以幫助專案管理員快速識別其成員的關鍵屬性，從而更有效地進行使用者管理。它包括更具描述性的術語，新佈局，所有列的標題，關鍵資料元素的工具提示等。
新的合併請求指標：平均合併時間（PREMIUM及以上）專案級合併請求分析中提供了新的度量標準，即平均合併時間（MTTM）。MTTM是從建立合併請求（MR）到合併時間的平均時間。透過在日期範圍選擇器中選擇不同的日期，可以檢視合併MR的時間如何隨時間變化，並瞭解在瀏覽和合並程式碼方面是否變得更有效率。
對組和專案問題進行批次編輯迭代（PREMIUM及以上）新版本中，可以不必一次在一個問題上手動更新迭代，可以從組或專案的問題列表中批次更新迭代。
按里程碑過濾路線圖（PREMIUM及以上）戰略計劃或報告交流中，對當前進行中的工作需要能夠重點關注和過濾路線圖的檢視。13.9中，透過按里程碑過濾可見的Epic，進一步完善里程圖檢視。
結果，合併請求作者常常被迫壓縮整個合併請求的提交，或者不得不在本地手動應用建議，或者在應用建議後返回並重新編寫提交。
在新版中，應用建議時可以編寫自定義提交訊息。這使作者和貢獻夥伴可以接受建議，並遵循其專案的提交訊息最佳實踐。如果未指定自定義提交訊息，則使用預設的提交訊息來提交建議。
使用GitLab API建立變更日誌之前，GitLab生成變更日誌需要手動操作。版本管理者必須收集給定版本的所有更改，然後將它們手動新增到變更日誌檔案中，這既耗時又容易出錯。為了簡化該過程，13.9中添加了一個API，該API將基於提交歷史為給定版本自動生成變更日誌。透過為每個發行版提供一組一致且全面的變更日誌，開發團隊可以更好地與終端使用者交流變更。
合併引用以進行合併請求中的更改合併請求的diff已經透過計算git diff target...source其比較HEAD所述目標的與合併基礎target和source。這很好，直到目標分支中的更改合併到源分支中為止，從而形成了完全的差異。
現在<default branch> (HEAD)，在檢視合併請求的“更改”選項卡時，預設情況下將合併請求與之比較。這樣可以在稽核過程中提供更準確和最新的更改差異。
訪問Webhook管道觸發CI/CD作業中的有效負載當使用Webhook觸發管道時，無法從所得管道中的任何作業訪問Webhook的有效負載。在某些情況下，有效負載會攜帶重要資訊，這些資訊可以確定觸發的管道應如何工作。在新版本中，添加了一個新的預定義變數來捕獲webhook有效負載，因此使用者可以輕鬆地將其合併到觸發的管道中。
藉助產品內幫助更輕鬆地安裝GitLab Runner當使用共享執行程式時，要開始使用GitLab CI，需要安裝GitLab執行程式並註冊執行程式以在管道中執行作業。儘管GitLab Runner安裝過程有充分的文件記錄，其目標之一是使使用者儘可能輕鬆地開始使用GitLab CI。該過程的第一步是釋出一個新的GitLab Runner指導的安裝模式視窗。使用此功能，可以選擇目標平臺，複製並執行安裝命令，而無需離開GitLab UI。
重複的Maven上傳設定使用者可以使用GitLab軟體包登錄檔透過Maven或Gradle釋出Java依賴項。預設情況下，可以多次釋出相同的軟體包名稱和版本，類似預設的設定最常見的公共登錄檔的行為。
為了避免重複上傳，新版本中為Package Registry添加了新的組設定，使用該設定可以選擇是允許還是禁止重複的Maven或Gradle上傳。如果不設定，預設情況下將允許重複。
可以使用GitLab API來修改該設定，也可以在“設定”>“軟體包和登錄檔”配置。
鍵盤快捷鍵可在GitLab和GitLab Next之間切換13.9中引入了一個鍵盤快捷鍵，可以在GitLab和GitLab Next之間切換。透過使用g和x鍵，該鍵可在GitLab的任何區域使用，可以輕鬆地實現GitLab和GitLab Next之間切換。
Kubernetes代理伺服器的ConfigMap支援（PREMIUM及以上）截止當前，使用Kubernetes代理伺服器（kas）的使用者都必須使用命令列引數來自定義其代理伺服器安裝。事實證明，這種設定非常不利於以進行大規模部署安裝，而宣告式，可重複設定是工作流的核心部分，並且許多引數都需要自定義設定。在13.9中，可以透過自定義配置安裝Kubernetes Agent Server Helm Chart，這些自定義配置將與預設配置結合，從而可以輕鬆地將Agent Server部署與現有的觀察性和監視工具整合在一起。
將事件分配給里程碑並非所有事件的嚴重性都相同。為了恢復服務，時常需要同時並行處理很多事件。但是某些事件不太重要，可以將其排在其他工作之前，並可以排定特定的釋出日期或實施。新版本中，可以從右側工具欄中為里程碑分配低嚴重性事件，以便從問題面板管理它們。
Gitlab Runner 13.9同期還發布了GitLab Runner 13.9。新增加的功能包括：
Kubernetes執行器增加對Nvidia docker執行時的支援；
控制快取ZIP壓縮級別；
顯示工件/快取上傳進度；
在Windows幫助程式中將PowerShell核心升級到7.1.1；
在Linux上的Docker executor中啟用PowerShell Core支援；
在Kubernetes執行器中啟用PowerShell Core支援；
使用依賴代理自動進行身份驗證；
使用配置的幫助程式映像更新Kubernetes執行程式中的許可權；
在OpenShift上使用帶有runner的自簽名證書連線到gitlab例項。
Bug修復：Gitlab CI指令碼未正確傳遞上一個命令的退出程式碼的bug；
Windows服務“關閉超時”問題；
重複字元的可變遮蔽問題；
未使用配置對映中定義的config.toml的OpenShift Operator-concurrent屬性。
GPU計算和智慧排程支援在類似機器學習等的計算密集型工作中，使用GPU可以極大提高效能。開發人員可以透過轉發--gpu標誌，將GitLab Runner配置為利用Docker執行程式中的GPU。還可以將其與Docker Machine的GitLab分支中的最新支援一起使用，可以讓使用者透過連線的GPU加速工作負載。
GitLab Helm chart改進GitLab頁面的訪問控制支援Kubernetes部署。
可以以更可配置的方式在所有物件（例如部署和水平吊艙自動縮放器）上設定標籤。每個子圖表都有一個新common.labels設定。
可以啟用代理協議支援，以在具有新增代理協議標頭（例如AWS ELB）的上游代理的環境中支援SSH。
redis已更新至6.0.10和gitlab-exporter v10
Omnibus的改進GitLab的儲存庫安裝指令碼現在將CentOS 7軟體包用於Amazon Linux 2系統。Amazon Linux 2上現有的GitLab部署可以重新執行安裝指令碼以進行更新。注意目前尚未正式支援Amazon Linux 2 。
附帶套件包軟體分別升級為：redis 6.0.10、 logrotate 3.18.0，libtiff為 4.2.0
GitLab 13.9附帶的Mattermost升級為5.31.1，其最新的擴充套件支援版本提供了錯誤修復，以提高穩定性並改進外掛。此版本還包括安全更新，建議從早期版本進行升級。
安全和合規性審計容器網路策略警報的安全告警儀表板（ULTIMATE）新版本中新增加了全新的安全告警的儀表板。使用者現在可以配置容器網路策略以將告警傳送到安全告警儀表板。當必須對流量進行嚴密監控但不能在不對業務造成負面影響的情況下將其完全阻止時，該功能特別有用。可以在“安全性和合規性”>“威脅管理”>“策略”中配置警報， 然後在“安全性和合規性”>“威脅管理”>“告警”中檢視告警。
JavaScript和Python支援覆蓋率指導的模糊測試（ULTIMATE）13.9中可以對Python和JavaScript應用程式執行覆蓋率指導的模糊測試。和其他支援的語言工作流程相同，需要建立一個模糊測試作業以在管道中執行。當GitLab執行它時，模糊測試結果都會自動出現在“安全性儀表板”和管道的“安全性”選項卡中。
從漏洞建立Jira問題（ULTIMATE）許多客戶將Jira用作跟蹤問題和工程工作。當將GitLab用於SCM和CI/CD時，可以利用Jira整合來傳遞來自MR的資訊並提交到現有的Jira問題中。但是，還沒有辦法將有關安全掃描程式檢測到的漏洞的資訊自動反饋給Jira，需要使用者手動將漏洞資訊複製到新的Jira問題。
為了解決這個問題，13.9中引入了一種直接從漏洞的詳細資訊建立Jira問題的新功能。在現有的Jira整合設定中將其視為新選項。只需啟用新選項，然後選擇所需的Jira發行型別。可根據當前配置的Jira目標專案自動提取可用的問題型別。一旦啟用，專案中可以從漏洞建立GitLab問題的所有位置將直接建立配置型別的Jira問題。
允許部署金鑰推送到受保護的分支在GitLab 12.0之前，具有寫訪問權的部署金鑰可以將提交推送到受保護的分支。由於安全方面的考慮，已刪除了對此的支援，但是許多使用者還在使用它，他們需要這個方法來確保只有具有部署金鑰的使用者才能推送到其儲存庫。它還消除了使用服務使用者或機器使用者的需要，這為希望將部署金鑰推送到針對該用例的受保護分支的任何團隊捆綁了許可證。
新版本中已解決了此問題，現在部署金鑰可以再次遵守受安全保護的最佳做法，同時推送到受保護的分支。透過轉為部署金鑰的隔離許可權模型，使用者現在可以選擇“部署金鑰”以直接從受保護分支的設定頁面連結到受保護分支。
撤銷PAT/SSH金鑰時的電子郵件通知（ULTIMATE）管理名稱空間包括確保使用者瞭解誰有權訪問以及如何訪問。為了提高個人訪問令牌（PAT）的安全性，應該能夠在適當的時候撤消使用者的PAT。為了支援此控制元件，新添加了一個“撤消”按鈕，自建例項的管理員根據需要撤消這些憑據。現在，可以在一個介面中從憑據清單管理使用者的PAT和SSH金鑰。
透過機密性過濾路線圖（ULTIMATE）檢視路線圖時，曾經沒有辦法從主檢視中隱藏機密Epic。如果想對外分享路線圖，這可能會令人沮喪。
在新版本中，更新了搜尋欄過濾器以包括機密性。現在，可以在另一層中最佳化路線圖。
為sbt 1.3.0添加了依賴性掃描支援（ULTIMATE）使用sbt1.3及更高版本的Scala專案的使用者現在可以從“依賴項掃描”中受益。以前僅sbt支援1.2及以下版本。
改進的Android SAST支援從GitLab 13.5開始，已經透過MobSF支援移動SAST。該分析儀更新為2.5版，其中包括對Android移動掃描功能的許多改進。主要改進包括：新增OWASP MSTG對映以改善漏洞資訊，對Android 10 API 29的支援，xapk支援以及對Android的國家資訊保障合作伙伴（NIAP）分析。
截止當前Mobile SAST安全掃描器是實驗性的，需要透過CI變數SAST_EXPERIMENTAL_FEATURES啟用。
.NET SAST掃描的多專案支援GitLab安全掃描會自動檢測程式碼語言並執行適當的分析器。使用monorepos，微服務和多專案儲存庫，單個GitLab儲存庫中可以存在多個專案。以前，.NET SAST工具只能檢測儲存庫中的單個專案。在13.9中， NET SAST分析器現在可以智慧地檢測.NET專案中的多個解決方案檔案（.sln），並報告其中的漏洞。對於具有多專案.NET儲存庫的使用者來說，這使SAST掃描變得更易用、更精煉。
所有使用者的“安全配置”頁面透過所有GitLab客戶都可以使用SAST和Secret Detection，希望為啟用可用安全掃描的開發人員改善體驗。之前已經為Ultimate使用者提供了指導性的配置體驗，並且現在已經為所有使用者提供了這種體驗的簡化版本。這種新的配置體驗使開發人員更容易瞭解他們可以使用哪些安全掃描，查詢相關文件並提供簡單的啟用工具。在該版本中，支援建立SAST合併請求的按鈕。在將來的版本中，還將新增其他按鈕以輕鬆啟用其他掃描型別。
依賴關係掃描現在支援npm鎖定檔案v2（ULTIMATE）現在支援具有使用npm 7的鎖定檔案版本2的節點專案的使用者。以前，“依賴項掃描”將輸出以下錯誤：[FATA] [Gemnasium] [2020-10-29T19:02:20Z] ▶ Wrong file format version。
在SAST掃描中擴充套件了對Ruby的支援靜態應用程式安全測試（SAST）透過允許開發人員在貢獻程式碼和主動緩解程式碼時輕鬆識別常見的安全問題，從而幫助防止了安全漏洞。已經將RoRs SAST分析器（Brakeman）更新到新版本（v5），該版本增加了對大多數Ruby檔案的支援，而不僅僅是Rails專案。此更改擴充套件了Ruby專案的型別，並引入了新的檢測規則。如果一個自定義SAST.gitlab-ci.yml檔案，或覆蓋了GitLab SAST制動工，則可能需要更新CI檔案以啟用該附加掃描。
許可證掃描現在開始於其階段（ULTIMATE）以前，預設行為是在管道啟動時啟動許可證掃描。該行為是意外的，並且與其他GitLab Secure作業不一致。新版本中已更改了該預設行為，以便許可證掃描在啟動階段時開始，而不是在管道啟動時開始。如果已自定義.gitlab-ci.yml檔案，並且希望許可證掃描作業僅在其階段開始時才開始，請刪除該needs:[]語句。如果使用預設模板並希望還原行為，請新增該needs:[]語句。
對.NET 5的SAST支援Microsoft .NET 5.0版本是.NET Core的下一個主要版本，與.NET Core或.NET Framework相比，它支援更多型別的應用程式和平臺。已經更新了.NET SAST分析器安全程式碼掃描，以支援此新版本，現在SAST語言檢測也支援該新版本，從而使GitLab SAST能夠自動檢測.NET 5專案。
漏洞報告活動過濾器（ULTIMATE）漏洞報告通常是安全團隊分類和管理漏洞的主要方式。當前的過濾和排序選項提供了快速的方法，將列表檢視集中在漏洞的子集上，以實現更高效的工作流程。還可以檢視具有相關問題或後續掃描表明已解決的所有漏洞。“活動”列一目瞭然地表明哪些漏洞可能已經準備好被關閉，哪些正在進行中，以及哪些漏洞可能需要引起注意。但是，此列不是可以過濾或排序的列！
現在，透過引入“活動”過濾器，可以進一步控制“漏洞報告”的經驗。透過新的篩選器，可以在專案，組和安全中心漏洞報告中使用該漏洞，檢視具有尚未解決，已解決但沒有關聯問題，有問題和已解決或沒有活動的問題的漏洞。可用的篩選器選項是互斥的集，使可以精確鑽取執行任何任務所需的漏洞列表檢視。
支援PRIVATE-TOKEN使用Release-CLI建立發行版在新版本中增加了使用release-cli和建立釋出API文件中PRIVATE-TOKEN定義的的功能。透過允許連線專案級別或使用bot使用者帳戶的，可以覆蓋建立釋出的使用者，並支援自動化。PRIVATE-TOKENPRIVATE-TOKEN
Vault JWT（JSON Web令牌）支援GitLab環境。為了簡化與HashiCorp Vault的整合，Gitlab提供了Vault JWT令牌支援。從啟動開始，可以基於JWT中的資料限制訪問。13.9中提供了一個新的維度來限制對憑據的訪問：作業針對的環境。
此版本擴充套件了現有Vault JWT令牌，以支援基於環境的限制。由於environment名稱可以由執行管道的使用者提供，因此建議將新的基於環境的限制與已經存在的ref_type值一起使用，以實現最大的安全性。
使用依賴代理時自動進行身份驗證透過從Docker Hub代理和快取容器映像，Dependency Proxy可以幫助提高管道的效能。即使打算將代理與CI/CD一起大量使用，但要使用此功能，也必須將憑據新增到DOCKER_AUTH_CONFIG CI/CD變數中或docker login在管道中手動執行。這些解決方案效果很好，但是當考慮.gitlab-ci.yml需要更新多少檔案時，如果GitLab Runner可以自動進行身份驗證會更好。
由於Runner已經能夠透過整合的GitLab容器登錄檔自動進行身份驗證，因此能夠利用該功能來幫助您透過Dependency Proxy自動進行身份驗證。
現在，使用Dependency Proxy從Docker Hub代理和快取容器映像變得更加容易，並開始擁有更快，更可靠的構建。
效能改進在GitLab 13.9中，在問題，專案，里程碑等方面做了效能上的最佳化。GitLab 13.9中的一些改進是：
多標籤搜尋速度提高5到10倍；
MR Analytics頁面載入速度提高了7倍以上；
在Elasticsearch計數上設定1秒伺服器端超時；
改進渲染路線圖時的史詩限制；
減少小型例項上的Puma記憶體消耗預設情況下，GitLab使用的Web應用伺服器Puma使用多個工作程序來提高效能。這對於擴充套件GitLab很重要，但也會導致記憶體消耗增加。
對於使用者較少，資源有限的小型例項可能不需要多工作程序。對於這樣的需求，新版中支援在單一模式下執行Puma，從而將靜態應用程式的記憶體消耗減少了約250 MB。
Bug修復GitLab 13.9中一些值得注意的錯誤修復是：
開啟“管理員設定”頁面會導致500錯誤；
當不存在filename屬性時，單元測試報告未填充；
用點“.”構建。以他們的名字命名無法在使用者介面中載入測試詳細資訊；
如果標籤名稱包含點“.”，則專案標籤API返回“404 Label Not Found”。
SAST缺陷查詢器在SAST CI作業中失敗，出現UnicodeDecodeError錯誤;
SAST安全程式碼掃描崩潰：“index out of range error”;
內務管理未在Wiki倉庫上執行，導致效能隨時間下降;
根據漏洞詳細資訊建立問題-編輯的文字被丟棄;
GraphQL中的漏洞描述為空;
網路策略預覽deny all顯示為allow all;
將影象附加到票證時出現錯誤“Filenames contained invalid characters”;
not_adjacent 移動設計時出現錯誤;
路線圖中的錯誤，其中史詩在使用者介面中出現兩次;
從子組新增子Epic時，添加了錯誤的Epic;
GEO：修復併發的VerificationBatchWorker作業;
gitlab-ctl Promotion-preflight-checks錯誤地失敗，為0%;
UpdatePagesService作業可能導致備份作業失敗，並顯示錯誤“directory has vanished”;
依賴性掃描分析器未針對特定客戶的每次掃描更新漏洞資料庫。;
透過問題更新API建立的資源事件未遵循該updated_at引數;
API中的專案名稱到路徑轉換會破點符號“.”;
迭代報告未正確定義範圍;
“列出管道作業” GitLab API不再返回有關撤銷作業的資訊;
即使需要失敗的作業，也不會跳過使用DAG的延遲和手動作業;
GitLab 14.0將用Trivy替換其容器掃描引擎。當前，GitLab使用開源Clair引擎進行容器掃描。GitLab 13.9棄用了Clair。這並不是一項艱鉅的更改，因為希望繼續使用Clair的客戶可以透過將CS_MAJOR_VERSION變數設定為gitlab-ci.yaml檔案中的版本3（或更早版本）來這樣做。但是，由於不推薦使用Clair，因此請注意，從14.0版本開始，GitLab將不再更新或維護該掃描引擎。我們建議客戶使用從GitLab 14.0開始的Trivy的新預設值進行定期更新和最新功能。客戶可以提供反饋，並獲得有關我們的公開折舊問題的更多詳細資訊。
容器登錄檔日誌格式化程式變更日期：2021年2月22日
GitLab支援的日誌格式包括：
應用程式日誌的文字，JSON和logstash日誌格式。
用於訪問日誌的文字，JSON和組合日誌格式。
13.9中放棄對logstash和組合格式支援，僅使用兩個選項文字（用於開發）和JSON統一應用程式和訪問日誌的格式化程式。
容器登錄檔當前支援只能用於電子郵件通知的日誌記錄Hook。
基於日誌條目的警報通常由單獨的工具處理。據統計,使用者都沒有依賴此功能，GitLab也未使用它。該功能的實現與底層的日誌記錄庫緊密耦合，這是在不影響可用功能的情況下切換依賴關係的能力的限制。
當前為Redis連線池公開的一些配置設定與基礎Redis客戶端繫結，並且在替代庫中沒有等效設定。在我們開始改進Redis整合（例如增加對Sentinel的支援）的工作時，決定開始著手嘗試以功能更豐富的替代方法來替換當前的Redis客戶端依賴項，從而更好地為其提供支援。為此，需要替換繫結到當前客戶端庫的當前Redis池配置設定。預計將：
新增redis.pool.size（最大連線數），redis.pool.minidle（最小空閒連線數）和redis.pool.maxlifetime（可以重用連線的最大時間）設定。
Container Registry不再支援TLS 1.0和1.1的變更日期：2021年2月22日
出於安全性考慮，由於GitLab不再支援TLS 1.0和TLS 1.1。將對當前支援1.0（預設），1.1、1.2和1.3的GitLab容器登錄檔進行同樣的操作。且預設為1.0。
為確保秘密檢測同時掃描預設分支和功能分支，在託管模板中引入了兩個單獨的秘密檢測CI作業。這兩個CI作業secret_detection_default_branch和secret_detection在CI規則邏輯中造成混亂和複雜性。作為不推薦使用的一部分，將確定工作執行方式的rule邏輯（歷史記錄，分支上的提交，提交等）轉移到了邏輯中。如果重寫或維護的自定義版本，必須更新您的CI模板。強烈建議繼承並覆蓋託管CI模板，以便將來證明您的CI模板。將在2021年5月22日釋出的GitLab 14.0中停止支援舊工作。
自GitLab 13.0起提供基於GitLab Pages API的配置，它將替換disk源配置，該配置將在GitLab 14.0中刪除。建議不要使用disk源配置，而轉而使用gitlab基於API的配置，因為disk將不再支援並且無法選擇它。您可以透過gitlab_pages['domain_config_source'] = "gitlab"在gitlab.rb/etc/gitlab/gitlab.rb檔案中進行設定來從“磁碟”源配置中遷移。建議在GitLab 14.0之前執行此操作，以便提前發現並解決所有潛在問題。
棄用使用Docker登錄檔API v1的請求變更日期：2021年2月22日
透過完成以下步驟，GitLab上的v1登錄檔API的現有使用者可以移至v2登錄檔API：
將Docker Engine更新到17.12或更高版本，以便與v2登錄檔API相容。如果在GitLab中具有v1格式的內容，則可以使用較新的Docker客戶端（比1.12更新的版本）將其移至v2格式，以重建映像並將其推送到GitLab。
GitLab 13.5中釋出了SAST自定義規則集，為Go分析器（GoSec）的配置選項提供了更大的靈活性。為了提高靈活性，將放棄對SAST_GOSEC_CONFIG分析儀設定。該變數將在GitLab 13.10中棄用，並在GitLab 14.0中予以刪除。如果覆蓋或利用SAST_GOSEC_CONFIG了CI檔案，則需要更新SAST CI配置或將其固定到GoSec分析器的舊版本。強烈建議繼承並覆蓋我們的託管CI模板，以便將來證明您的CI模板。將在SAST_GOSEC_CONFIG variable在2021年5月22日釋出的GitLab 14.0中刪除舊版本。
以前，要排除DS分析器，需要將其從分析器的預設列表中刪除，然後使用它DS_DEFAULT_ANALYZERS在專案的CI模板中設定變數。確定，在不失去新新增的分析儀優勢的情況下，避免執行特定的分析儀應該更容易。因此，要求您從可用時遷移DS_DEFAULT_ANALYZERS到DS_EXCLUDED_ANALYZERS。以前，為了防止Gemnasium分析器在執行時獲取諮詢資料庫，需要設定GEMNASIUM_DB_UPDATE env變數。但是，此檔案未正確記錄，並且其命名與等效BUNDLER_AUDIT_UPDATE_DISABLED變數不一致。因此，要求從可用時遷移GEMNASIUM_DB_UPDATE到GEMNASIUM_UPDATE_DISABLED。
發現漏洞，模糊測試作業將失敗並顯示allow_failure變更日期：2021年5月22日
為了確保模組測試作業彼此一致，在14.0中，如果一個模糊測試作業發現漏洞，所有模糊測試作業都將開始失敗。這些作業將allow_failure=true在其中設定，因此將收到警告，但如果發現漏洞，整個管道不會失敗。
這是幾種模糊掃描器（例如Go和C ++模糊引擎）的當前行為。
無需採取任何措施即可使用此新行為。如果要作為指令碼的一部分檢查管道模糊測試任務的結果，請考慮這些指令碼是否需要任何更新。
Git預設分支名稱更改變更日期：2021年4月22日
GitLab Runner安裝程式忽略skel目錄變更日期：2021年6月22日
在GitLab Runner 14.0中，skel預設情況下，安裝過程將在建立使用者主目錄時忽略該目錄。
Helm v2支援變更日期：2021年5月22日
Helm v2於已於2020年11月停止支援，該stable儲存庫此後不久便從Helm Hub取消列表。GitLab 14.0的釋出中（其中包括GitLab Helm圖表的5.0版本），將不再支援Helm v2。
舊功能標誌棄用變更日期：2021年5月22日
傳統功能標誌在GitLab 13.4中變為只讀。在GitLab 14.0中將刪除對舊功能標記的支援。必須將舊版功能標誌遷移到新版本。為此，可以先對舊式標誌進行抓屏以進行跟蹤。然後透過API或UI刪除該標誌（無需更改程式碼），並建立一個與您刪除的舊標誌同名的新功能標誌。另外，請確保策略和環境與已刪除標誌匹配。
限制在GET/groups/:id/中返回的專案變更日期：2021年5月22日
為了提高效能,將GET/groups/:id/API呼叫返回的專案數限制為100。要獲取專案的完整列表，請使用GET/groups/:id/projects API呼叫。
將pwsh設為新註冊的Windows Runner的預設外殼變更日期：2021年6月22日
在GitLab Runner 13.2中，PowerShell Core支援已新增到Shell執行程式中。在14.0中，pwsh它將是新註冊的Windows執行程式的預設外殼程式。Windows CMD仍可作為Windows執行程式的外殼程式選項使用。
從SAST_DEFAULT_ANALYZERS遷移到SAST_EXCLUDED_ANALYZERS變更日期：2021年2月22日
在13.9之前，要避免執行一個特定的GitLab SAST分析儀，則需要將其從檔案中較長的分析儀字串中SAST.gitlab-ci.yml刪除，然後使用它SAST_DEFAULT_ANALYZERS在專案的CI檔案中進行設定。該字串對執行的分析器列表進行了硬編碼。透過反轉此變數的邏輯以排除在外，而不是選擇預設分析器，為了避免此問題。13.9開始，正在遷移到SAST_EXCLUDED_ANALYZERS我們的SAST.gitlab-ci.yml檔案。建議在專案CI檔案中使用自定義SAST配置的遷移到此新變數。如果尚未覆蓋SAST_DEFAULT_ANALYZERS，則無需採取任何措施。SAST_DEFAULT_ANALYZERS 將在2021年4月22日釋出的GitLab 14.0中刪除。
將靜態分析儀和工具固定到次要版本變更日期：2021年3月22日
隨著GitLab Secure掃描工具的成熟，需要在SAST分析儀的版本控制中增加更多的粒度。此項更改將使客戶可以更輕鬆地專門設定要執行的分析儀的版本，從而為客戶選擇升級SAST掃描方式提供了更多控制。在13.10之前，GitLab為我們所有的SAST分析器和工具共享了一個主要版本號，並禁止使用語義版本號進行更新。
從13.10開始，GitLab SAST和Secret Detection將開始major.minor在.gitlab-ci.yml檔案中使用版本固定，並將major.minor標籤傳送到分析器容器上。還將刪除SAST_ANALYZER_IMAGE_TAG託管的SAST.gitlab-ci.yml CI模板中的major.minor變數，以使用每個分析器的標籤為好。如果覆蓋或維護的自定義版本SAST.gitlab-ci.yml，Secret-Detection.gitlab-ci.yml或依靠分析器x-y-stable標籤，則需要更新CI模板。強烈建議繼承並覆蓋託管CI模板，以便將來證明您的CI模板。透過此更改，可以改用固定的major.minor版本進行覆蓋，以更精細地控制將來的功能更新。將刪除共享的主要版本固定和SAST_ANALYZER_IMAGE_TAGSAST.gitlab-ci.yml GitLab 14.0管理的變數，於2021年5月22日釋出。
PostgreSQL 11支援變更日期：2021年5月22日
PostgreSQL 12是GitLab 14.0中最低要求的版本。它為索引編制，分割槽和一般效能優勢提供了重大改進。
從GitLab 13.7開始，所有新安裝的預設版本均為12。從GitLab 13.8開始，單節點例項也將自動升級。如果還沒有準備好升級，則可以選擇退出自動升級。
在使用Patroni進行升級之前，多節點資料庫例項將需要從repmgr切換到Patroni。然後可以更新GEO資料庫並重新同步。
在GitLab Runner 13.1中，引入了Shell執行器sigterm，然後介紹sigkill了該過程。並添加了一個新的功能標誌，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此可以使用以前的過程終止序列。在GitLab Runner 14.0中，將刪除功能標記。
在GitLab runner13.2翻譯step_script到build_script被新增到自定義執行。在14.0中，“ build_script”階段將替換為“ step_script”。
更新Auto DevOps中穩定的Auto Deploy模板變更日期：2021年5月22日
在GitLab 14.0中，將把Auto Deploy CI模板更新為最新版本。這包括對v2 auto-deploy-image的依賴關係的新功能，錯誤修復和效能改進。該最新模板已啟用。除非您在專案中專門自定義Auto DevOps，否則它將使用穩定的模板，該模板依賴於v1 auto-deploy-image。
由於v1和v2版本不向後相容，因此如果已經有已部署的應用程式，則專案可能會遇到意外故障。
對於GitLab自建例項，將安全使用Puma伺服器變更日期：2021年5月22日
14.0中/etc/gitlab/gitlab.rb將不再支援下述的配置設定：
geo_secondary['db_fdw']geo_postgresql['fdw_external_user']geo_postgresql['fdw_external_password']gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']變更日期：2021年5月22日
在升級到GitLab 14.0之前，必須 完全遷移到雜湊儲存。
升級更新Omnibus版升級透過Omnibus安裝的自建例項可直接使用Linux包管理器可以升級。例如對CentOS:
yum updata/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 pulldocker-compose up -dCohorts是GitLab自建例項的管理區域中可用的功能。顯示了有多少個新使用者已新增到GitLab，其中有多少成為活動使用者，以及自新增以來，有多少使用者繼續每月使用GitLab。在GitLab 13.9中，同類群組已從“分析”部分移至“概述”>“使用者”部分，以便可與其他使用者指標一起發現。