按照預定的版本計劃，前天GitLab官方博客宣佈GitLab 12.8發佈。新版本繼續加強DevOps功能及其生命週期的管理，包括了日誌瀏覽器、NuGet軟件包和遵從性活動等。更詳細功能，請隨蟲蟲一起來學習。
主要功能
新的Log Explorer進行日誌匯聚管理（ULTIMATE）
在對事件進行分類或驗證服務狀態時，需要能夠從整個應用程序中瀏覽Kubernetes Pod日誌。此前日誌的瀏覽非常麻煩，只能看到有限的日誌，無法來回回溯訪問過也不支持日誌搜索。無法使用Pod Logs進行有意義的分析，只能用於簡單的故障排除用例。
現在，新的Log Explore支持彙總所有日誌到一個位置進行交互。其強大的功能包括日誌過濾，按照時間篩選以及支持全文搜索，可快速獲取所需的信息。日誌記錄類別從minimal移到viable。
對GitLab自建實例，可以一鍵安裝Elastic stack安裝到Kubernetes集群上，所有日誌將被自動收集和彙總。
GitLab 12.8引入了使用彈性堆棧的日誌聚合。附加Kubernetes集群后，可以安裝Elastic堆棧，其中包含一個帶有Filebeat（輕量級日誌傳送器）的Elasticsearch實例。啟用後，GitLab會自動收集所有應用程序日誌並將其顯示在UI上。
通過日誌匯聚，可以查看跨多個服務和基礎架構的彙總Kubernetes日誌，及時返回，進行無限滾動以及搜索應用程序日誌。如果要對應用程序事件進行分類或驗證服務狀態，並且需要瀏覽整個應用程序中的日誌並進行全文搜索，這將非常有用。可以幫助瞭解影響應用程序性能的因素，並解決出現的任何問題。
高效地存儲和共享C＃和.NET資源（PREMIUM及以上）
Windows具有龐大，活躍且不斷髮展的開發社區。儘管GitLab已經具有針對C/ C++，Java和Node.js的內置軟件包管理，但是使用c#和.NET應用程序仍需要藉助外部的工具來保存和管理其二進制文件。
GitLab 12.8中新增加了NuGet存儲庫，以支持對C#和.NET應用的管理。可以在通過一個地方私下和公開地管理和共享項目二進制文件。現在，開發人員可以從其源代碼，CI/CD管道以及生成的程序包都可以通過NuGet來交互管理，從而以更少的精力更快地完成工作。
單級Epics現已提供高級版（PREMIUM及以上）
為了支持正在計劃大量相關工作並在團隊的多個里程碑，衝刺和迭代中對其進行管理的用戶，新版本將為高級客戶發佈單級Epics。
啟動一個Epic，創建和添加相關問題，設置開始日期和截止日期，並使用拖放Epic Tree快速組織它。
問題的已阻止狀態（STARTER及以上）
明確定義問題依存關係變得更加容易。新版本中可以將問題標記為已阻止或被其他問題阻止。通過這種新的依賴關係構造，現在比以往任何時候都更容易理解可能需要額外關注的問題（被阻止），或者識別將產生高回報的問題（被阻止）！由於現在可以表示團隊之間的依存關係，因此協作效率也得到了提高。
問題面板工作進度限制（STARTER及以上）
給定工作流程階段中進行的問題越多，完成任何給定問題所花費的時間就越長。進行看板的團隊通常使用進行中的工作（WIP）限制，這是提高吞吐量的一種行之有效的方法。
從12.8版本開始，可以根據發行版中每個列表的最大發行量來設置WIP限制。如果超出限制，列表背景顏色將變為紅色。
發行板上對阻止的問題高亮顯示（STARTER及以上）
被阻止的問題需要注意。在查看問題面板時能夠區分哪些問題被阻止，這樣可以快速確定確定團隊進度的瓶頸。消除任務進展的障礙，從而提高團隊的效率比。
定時自動停止環境
新版本中，可以對環境設置到期時間，以在特定的空閒時間後自動停止。這對於短暫的環境（例如用於Review Apps的環境）特別有用，可以避免浪費資源。設置在主配置文件.gitlab-ci.yml文件，格式為auto_stop_in: 1 week。也支持在GitLab UI中覆蓋該設定。用戶還可以通過UI固定其特定環境並保持該環境的運行（無論該設置如何）來禁用自動停止。
通過防止出現許多陳舊環境的情況，不會通過保持基礎結構資源的運行而浪費它們。還將獲得回退的開發時間，否則這些時間將花費在手動停止環境上。
自動審查應用程序
網頁和應用程序的可訪問性已成為當今軟件開發人員日益關注的問題。然而，其可訪問性測試通常是在軟件開發過程的後期的問題。如果提前完全完成，通常這是一個手動且不一致的過程。開發團隊通常缺乏產品經理或產品設計師的明確要求，概述了構建應用程序時要遵循的可訪問性標準。
從GitLab 12.8開始，可以在Review App中自動掃描並獲得有關可訪問性問題的報告。通過使可訪問性問題的反饋迴路更加緊密，從而節省了開發時間，因此可以最大程度地影響所有用戶對應用程序的訪問。
支持為每個合併請求下載報告。
自動從跨項目作業中引入工件（PREMIUM及以上）
現在，可以指定項目中的作業依賴於另一個管道中的作業所產生的最新工件，這使得設置彼此之間具有工件依賴關係的跨項目管道變得更加容易。
例如，可能需要構建可執行二進制文件的管道。在此之前，即使庫沒有更改，也必須在每次構建二進制文件時都重新構建二進制文件所依賴的所有庫。這樣會有大量時間和算力的浪費，並且還需要使用API密鑰，cURL和安全變量的脆弱組合來進行變通。
新版本中，可以通過needs: 工作中指定artifacts: true，就可通過拉庫管道所產生的鏡像，並最終可執行的管道可用，而不需要重建。
受保護分支的合併請求批准規則（PREMIUM及以上）
代碼審查是每個成功項目的基本做法，並且可以使用批准規則來確保合適的人員審查每個更改。在練習連續交付或從事較高風險的項目時，這一點尤其重要。以前，添加更多限制性批准要求以保護默認分支將對每個分支施加相同的要求。這迫使所有合併請求都滿足相同的批准要求，無論是將錯誤修復程序合併master到發行分支還是兩個功能分支之間。
GitLab 12.8通過在在項目級別設置的合併請求批准規則可以根據合併請求的目標分支有選擇地要求來解決這個問題。這樣允許限制性批准規則準確地在需要時應用，甚至允許將不同的批准規則應用於不同的分支（例如穩定版本分支）。
S/MIME簽名驗證
Git存儲庫中的每個提交都有一個作者，但是沒有經過Git的驗證，這意味著創建看起來是由其他人創作的提交很容易。提交簽名可以用來對提交者驗證。這對於敏感項目和某些商業環境非常重要。
在Git 2.19中，OpenGPG簽名和驗證支持已擴展為包括使用X.509證書的S / MIME支持，對於大型組織而言，管理這些證書將更為友好。
在實例級別禁用自批准（PREMIUM及以上）
新版本中引入了新的實例級設置，通過將項目設置中的某些合併請求批准設置放入"管理區域"，以防止不必要的更改來合併請求批准設置。這將使管理員更好地控制其部署，並允許他們在部署代碼時保持職責分離。
通過在實例級別啟用這些設置，將強制自我管理實例中的所有項目採用這些設置，只有管理員才能為單個項目更改它們。這項新的強制執行功能可確保只有經過批准的部署才能投入生產，並使GitLab項目進入更合規的狀態。
元數據在Package Registry用戶界面中使用（PREMIUM及以上）
調查顯示，用戶需要導航到Package Registry UI，以驗證使用哪個版本的軟件包或驗證其管道是否正確構建了該版本。由於沒有在用戶界面中顯示有關軟件包構建方式的任何信息，因此用戶被迫需要在應用程序的多個不同區域之間切換。
在GitLab 12.8， GitLab管道構建將顯示pipeline_id，branch以及commit在包註冊表的用戶界面。這將幫助用戶瞭解軟件包的構建方式，並在出現問題時更輕鬆地進行故障排除！
通過API管理對受保護環境的訪問（PREMIUM及以上）
到目前為止，為受保護環境配置訪問級別的用戶需要通過"設置" UI（而非CLI）更新開發者和維護者權限。對於想要從命令行工作並需要在組之間維持相同級別的環境訪問的用戶而言，這效率不高。
在新版本中，維護人員可以在使用API添加或刪除對受保護環境的訪問時節省時間，而不是在"設置" UI中擁有更新權限。
通過代碼段啟用Review Apps
儘管可以配置.gitlab-ci.yml文件，新版本在環境頁面增加了Enable Review Apps按鈕以提高便捷性；如果使用Kubernetes，並且要啟用Review Apps，需要到.gitlab-ci.yml中的YAML代碼段啟用。
有向無環圖（DAG）管道中的作業可以在無任何前任的情況下進行設置
指定一個空needs:數組可用於向GitLab指示該作業沒有前身，並且無論它處於什麼階段，它都可以立即開始。可以使用它在DAG管道中建立更靈活的關係，加快速度並提高效率。
GEO改進許可證banner（STARTER及以上）
Geo僅在高級和終極層可用。以前，當嘗試使用Starter或Core許可證在管理員界面中啟用Geo時，會顯示該許可證無效或者不太有用。新版本中提供了一條更清晰的消息，指出正在使用哪個許可證，使用Geo需要哪個許可證，並且還提供了一個鏈接來管理許可證。
新審核事件（PREMIUM及以上）
為了提高自建實例和Gitlab在線倉庫組的可見性，在新版本中，添加了管理員操作來創建，阻止或刪除用戶，並在自建實例日誌中增加了用戶名更改事件。
這些新的審核事件將幫助注重合規性的組織保持職責分離，訪問管理和不可否認性。
指標圖比例
度量標準圖表上的y軸值以前總是從零開始。這使用戶難以檢測到度量標準圖表上的細微變化。從12.8版開始，y軸值將根據數據自動縮放。
指標儀表板中的可搜索環境
當有許多特定環境時，它們可能會變得很麻煩。現在，通過下拉菜單中的新搜索欄，可以在指標儀表板中快速找到想要查看的環境。
指標儀表板的柱形圖
在可視化指標時，用戶通常喜歡為不同的指標選擇不同類型的可視化。為了幫助實現這一目標，新版本在監視儀表板上添加了柱形圖作為新的可視化選項，以便按需顯示數據。
DigitalOcean S3上託管的GitLab容器註冊表解決Docker垃圾回收問題
有一個已知的Docker問題，其中具有絕對URI的所有請求的基於Ceph的存儲都會影響Docker垃圾回收過程。由於DigitalOcean中使用Ceph，因此用戶使用DigitalOcean進行存儲，它將阻止用戶運行垃圾回收。這導致這些用戶的存儲成本更高。
在GitLab 12.8中，通過更新Ceph的驅動程序以支持最新版本的API來解決了該問題。這使使用DigitalOcean進行GitLab容器註冊表存儲的任何組織都可以運行垃圾收集並降低其存儲成本。
更改服務檯用戶的名稱（PREMIUM及以上）
默認情況下，從GitLab服務檯發送的電子郵件來自GitLab Support Bot。很多時候，問題的發起者不經意會向GitLab發送電子郵件，這令人困惑。
現在可以為Service Desk用戶配置名稱。這樣可為用戶提供與品牌相匹配的可識別名稱。
使用CI/CD模板安裝更多Kubernetes應用程序
使用GitLab CI / CD安裝Kubernetes應用程序是一種在安裝前自定義應用程序的好方法。
在GitLab 12.8中，新模板可用於使用GitLab CI/CD 安裝JupyterHub和Elastic Stack。通過GitLab CI/CD安裝應用程序將另外啟用版本控制和對已安裝圖表的訪問控制。
使用早期Knative版本的文檔
隨著Knative接近1.0版，由於尚未解決Knative升級過程中的許多問題，許多GitLab用戶需要構建Knative的舊版本。出現問題是因為gitlabktl API更改導致的新版本僅支持特定版本的Knative。由於GitLab Serverless位於Alpha中，因此選擇不提供向後兼容性。
解決此問題的方法是使用的固定版本gitlabktl。儘管這一直是可能的，但要弄清楚卻並非易事。新版本文檔中添加了一組清晰的說明，以幫助發現和執行。
Web IDE的深色語法突出顯示主題
長期以來，GitLab支持替代語法突出顯示主題，以供在代碼審查過程中瀏覽存儲庫中的文件或查看差異時使用。但是代碼編輯器區域不支持使用此首選項，儘管這是Web IDE最需要的功能。
Web IDE現在在代碼區域中支持Dark語法突出顯示首選項。從該主題開始，將繼續擴展對Web IDE中語法突出顯示首選項的支持。深色主題將會擴展到Web IDE的其餘部分，包括文件樹和側邊欄。
利用策略刪除Docker鏡像
管道的建立涉及大量Docker鏡像構建，但是，其中許多鏡像僅在需要存在很短的。此前，還必須依靠通過Container Registry API或使用用戶界面刪除鏡像。
在12.8中，為所有新項目引入Docker標籤過期策略。這項新功能使用戶可以按名稱識別標籤，選擇保留標籤的版本以及定義何時應刪除標籤。例如，可以設置一個策略，該策略將刪除所有與策略正則表達式（如Git SHA）匹配的標記名稱，始終保留至少五張圖像，並刪除任何30天以上的圖像。
Geo實現開發人員自助服務（PREMIUM及以上）
Geo通過將數據複製到本地Geo節點來幫助分佈式團隊，並且還用於災難恢復。如今，Geo尚不支持 GitLab的某些功能。比如開箱即用的所有即將發佈的功能。為了實現這些功能的支持，方便GitLab社區中的開發人員更輕鬆地貢獻需要複製和驗證的新數據類型。通過標準化了Geo中使用的技術流程，以將Geo擴展到GitLab的其他部分，並且將為GitLab開發人員社區奠定堅實的技術基礎，以為Geo的未來功能和改進做出貢獻。有效地，未來的開發工作將更快，更高效。在12.8版本中，合併了重要的打包文件第一次迭代，從而為這項工作奠定了技術基礎。在下一次迭代中，將添加對包文件複製和驗證的支持。
GitLab NPM註冊表支持NPM分發標籤（PREMIUM及以上）
為了驗證其NPM軟件包已上傳或查找軟件包的正確版本，用戶希望使用軟件包元數據。NPM標籤可用於提供別名而不是版本號，從而使查找包變得更容易。例如，一個項目可能會選擇有發展的多個數據流，並使用不同的標籤為每個數據流，如stable，beta，dev，或canary。
在GitLab 12.8中，可在GitLab NPM註冊表中支持NPM分發標籤。可以支持添加，刪除和列出與註冊表中託管的任何程序包關聯的標籤，從而更快，更輕鬆地查找和發現程序包。
新規則語法中提供了允許失敗操作
擴展了新規則語法，現在可以定義允許失敗的管道規則。這在設置工作行為時為用戶提供了更大的靈活性，並使將其他項目遷移到更易於理解的新語法變得更加容易。
電子郵件中的擴展日誌長度
管道故障電子郵件中的日誌長度已從10行增加到30行，這使得查看更多跟蹤信息變得更加容易，並且更可能將完整的錯誤消息包含在電子郵件中。
解決相關Sentry錯誤後自動關閉問題
應用程序中管理錯誤非常困難，無需記住在修復錯誤後也要關閉GitLab問題。解決相關Sentry錯誤後，GitLab問題現在自動關閉。它消除了額外的手動工作，並避免了哪些問題仍然存在的困惑。
複製包含自定義指標的儀表板
以前，重複顯示板僅包含默認指標。通過12.8中的這一新增強功能，現在在克隆支持自定義指標和默認指標的默認儀表板時，將包括自定義指標。
GitLab自建控項目
GitLab管理員現在可以使用一個新的基礎項目來了解其GitLab實例的運行狀況，該項目將添加到" GitLab實例管理員"組下。創建用於可視化和配置關鍵指標以監視GitLab實例。
從指標圖表導航到日誌（ULTIMATE）
對事件進行故障排除時，同時查看日誌和指標很重要。新版本中在查看度量標準圖表時，無需保留GitLab控制檯，就可以在保留上下文的同時直接向下導航到日誌瀏覽器。
改進容器註冊表前端的Delete API的性能
GitLab容器註冊表用戶界面允許查看，發現和管理項目的鏡像。問題在於，刪除標籤是GitLab上執行效果最差的操作，有些請求最多需要60秒才能完成。這導致頁面加載時間變慢，並且支持請求的數量增加。
在GitLab 12.8中，此功能的性能提高了約70%。將大大改善頁面加載時間和可靠性。
拖放式設計徽章（PREMIUM及以上）
在問題的"設計"選項卡中查看設計時，可以在圖像的任何區域上放置註釋標記並附加註釋。這對於進行興趣點討論非常有用。但是，由於提供了反饋並上傳了新修訂，因此有時需要將徽標移動到新位置。此版本允許拖動徽章，可以
拖放評論到徽章之後。或者將其他人的徽章移到合適的位置。
進行版式修訂後，移動徽標以匹配新的設計。
在作業頁面上顯示Kubernetes命名空間
當CI/CD作業部署到Kubernetes環境時，作業詳細信息頁面現在將顯示用於該部署的Kubernetes命名空間。可以使用詳細信息頁面來驗證工作負載是否已部署到正確的目的地。
更快的存儲庫瀏覽器
Gitlab項目將變得更快。在GitLab 12.8中，當在目錄之間瀏覽時，文件列表和提交數據將被更新，無需重新加載整個頁面，減少了不必要的頁面加載。
標籤寬度用戶首選項
與空格相比，製表符不僅僅是某些選項的優先事項。對於使用製表符的人來說，正確的製表符寬度無關緊要。特別是對於製表符最常見的C和Go項目，重要的是，可以將製表符寬度配置為與本地首選項相匹配，以進行最佳的代碼審查。
現在，GitLab提供了Tab寬度用戶首選項，用於在Markdown中查看包括差異，CI日誌和渲染代碼塊的代碼時使用。
安全和合規性
實例級安全儀表板（ULTIMATE）
現在提供了安全漏洞的實例級視圖。使用此儀表板可以查看所有組和項目中可能存在的安全問題的概述。
除了查看項目中的漏洞列表以及一段時間內的漏洞趨勢之外，還可以查看所有組中按其安全報告字母等級分類的項目，以便快速決策哪個項目最需要注意。
合規性儀表板管理（ULTIMATE）
合併請求（MR）是一種優雅而強大的變更管理工具，用於記錄變更和批准。發佈團隊使用MR來跟蹤部署，而基礎架構團隊則使用MR來實踐GitOps。
此外，對於擁有特定公司政策來管理其運營以遵守合規性框架（例如SOC 2，ISO 27001，GDPR，SOX，HIPAA或PCI-DSS）的組織而言，跟蹤所有MR活動對於組織而言至關重要。規範其運營的公司政策。
政策合規治理一些用例包括：
所有MR都有一個相關的問題，其中包含有關更改的詳細信息；
所有MR均由非作者審核和批准；
所有MR均通過質量檢查和安全測試；
所有MR都有一個相關的問題，其中包含有關更改的詳細信息；
所有MR均由非作者審核和批准；
所有MR均通過了質量檢查和安全測試；
要求的任何例外都需要單獨批准。
以前，GitLab用戶缺少有效管理其GitLab環境的變更管理和合規性的必要工具。項目級別的活動僅限於單個項目，沒有簡單的方法可以在組級別查看這些信息。缺乏控制力和洞察力增加了潛在風險，降低了用戶在GitLab中管理合規性的能力。
遵守法規的組織需要可見性。隨著將更多的組，項目和用戶添加到GitLab，這變得更加困難，這可能使得難以適當地管理風險和合規性。
在GitLab 12.8中，新添加了一個組級別的儀表板，給組所有者一個合規性意見，重點是彙總組中每個項目的所有最新合併請求（已批准和合並）。群組所有者可以查看其所有合併請求活動，並在必要時採取措施。
Gitlab 12.8新添加了強大的合規性管理—— 合規性儀表板，該儀表板提供了對組中每個項目的最新合併請求的視圖。目前可用的功能，可以實現一處管理發佈和GitOps的代碼更改審核。同樣，這使注重合規性的組織更容易快速瞭解哪些項目可能面臨更大的風險，因此需要格外注意。
容器網絡安全的網絡策略（ULTIMATE）
新版本中實現對Container Network Security的初步支持，可以幫助用戶防止橫向安全攻擊。現在，可以在由GitLab管理的Kubernetes群集中配置網絡策略，以限制Kubernetes Pod之間的通信。
網絡策略可以控制Pod和Internet之間的通信，並且可以防止未經授權的Pod與同一Kubernetes集群中的其他Pod通信。在多應用程序群集中，此功能還支持不同應用程序之間的網絡分段。
在發佈結束日期收集發佈證據（STARTER及以上）
用戶首次創建發佈條目時，會在審核的情況下獲取元數據的快照以作為證據。從12.8開始，將會在發佈結束日期自動拍攝發佈證據的其他快照。通過提供第二個快照，可以將發佈的開始狀態與其結束狀態進行比較。這使審核團隊可以更好地瞭解這兩個時間點之間的變化。
在依賴項掃描中支持Go模塊（ULTIMATE）
新版本將支持對Golang模塊依賴掃描。但該功能當前處於Alpha狀態，數據庫僅包含2019年及以後的Go Module漏洞定義。
組管理帳戶的憑證清單（ULTIMATE）
要管理對GitLab組的訪問權限，需要了解這些組中執行操作所使用的憑據。
在GitLab 12.8中，憑據清單從自建實例擴展到了GitLab。現在，組管理帳戶的所有者可以查看其組中存在的SSH憑據和個人訪問令牌。清單會顯示用戶，憑證類型和到期日期，以便可以做出有關訪問和密碼輪換的操作。
快速更新的漏洞數據庫（ULTIMATE）
通過使用最新的漏洞來不斷更新漏洞數據庫，確保GitLab的掃描儀始終掃描到最新的漏洞，從而保護安全。
2020年2月，對已知漏洞，在漏洞發佈後的2.2天內將其添加到了數據庫中。
Omnibus的改進
Omnibus GitLab新版本中包括PostgreSQL 11作為PostgreSQL的可選版本。GitLab 12.8包含Mattermost 5.19，這是開源的Slack-alternative。此版本的Mattermost包括使用GitLab，一個Webex插件，在DigitalOcean上一鍵安裝Mattermost的一鍵安裝以及安全更新，從而加快了開發週期。
Omnibus支持 PostgreSQL 11
Omnibus GitLab軟件包現在引入PostgreSQL 11。PostgreSQL 11發行版包括對分區的增強和其他性能改進，在GitLab 13.x中以此為基礎來提高其整體速度和響應能力。PostgreSQL 11已通過Omnibus GitLab進行了完整的測試，以進行新安裝和升級，包括HA配置。正在對Geo進行測試。
GitLab 12.8可以選擇升級到PostgreSQL 11。有關升級的說明，請參閱升級說明。新安裝和從9.6的自動升級仍將默認為PostgreSQL10。PostgreSQL 11將在GitLab 12.10中去除，而最低要求的PostgreSQL版本在GitLab 13.0中去除。
建議不使用Geo的實例的管理員儘早升級到PostgreSQL 11，以從性能改進中受益併為在GitLab 13.0中刪除PostgreSQL 9.6和10.x做準備。
更智能的Git Packfile重用
在GitLab 12.8的GitLab Omnibus中引入了Git 2.24的補丁版本，並改進了Git packfile的重用性。
當客戶端獲取或克隆客戶端時，服務器通過儘可能重用現有的packfile來進行響應更加有效。這些改進實現了一種用於重用packfile的新的更智能的算法，該算法在提供克隆或獲取的成本與生成的packfile的質量之間做出了更好的折衷。
GitLab Runner 12.8
GitLab Runner 也一併發佈了12.8版本。主要亮點包括：
Kubernetes執行者應通過HostAliases公開服務
Bump Go至1.13.7
添加對
X-GitLab-Trace-Update-Interval標頭的支持
支持來自GitLab API的速率限制標頭
更多信息，請參考可以在GitLab Runner更新文檔。
性能改善
在GitLab 12.8中，將在問題，項目，里程碑等方面性能都有了大幅度的改善。主要包括：
從用戶通知設置中刪除N + 1；
從Todos頁面上刪除Gitaly通話；
將外鍵約束添加到Epics表；
修復Blob搜索API降級；
ES索引字段長度的應用限制；
按截止日期和位置排序時優化問題搜索；
按重量排序時優化問題搜索；
合併請求更改將逐步加載
合併請求，尤其是"更改"選項卡，是查看和討論源代碼的地方。以前，隨著提議的更改變得更大，差異將緩慢加載，並且在完全加載之前無法讀取。
在12.8中，文件更改列表會立即加載，並且差異會逐漸加載，因此幾乎可以立即開始閱讀差異，而不必等待頁面完全加載。
項目導入導出和更快，更可靠
GitLab 12.8對項目的導入和導出進行了重大改進，從而大大縮短了執行時間並提高了可靠性。
新版本中項目導出的完成速度提高了四倍，內存佔用量減少80%。以前，大型項目可能會由於超出導出作業的內存限制而無法導出。新版本中，這些任務將有可能獲得成功。
由於大大減少了數據庫調用，項目導入速度提高了約50%。將來，還計劃通過切換到以換行符分隔的JSON來減少導入所需的內存。
啟用Git delta islands核心
取決於磁盤上Git存儲庫中packfile的結構，克隆可能會佔用大量CPU和內存，因為Git可能需要即時構建和壓縮packfile。當大型存儲庫被同時克隆多次時（例如在並行CI管道中），可能會佔用大量CPU和內存。但是，如果觸發了packfile的重用，則Git不會立即構建響應，而是直接從磁盤流式傳輸packfile，從而消除了克隆中大多數CPU和內存的使用。
在GitLab 12.8中，當重新打包存儲庫時，將創建一個包含所有可訪問分支和標籤的增量島核心，以便在克隆Git存儲庫時觸發packfile重用。GitLab自動為活動存儲庫執行重新打包，但是也可以通過單擊項目"常規設置"中的" 運行內務處理"來手動觸發它們。注意，將淺克隆策略用於CI時，不會觸發packfile重用。
改進了S3的GitLab容器註冊表垃圾收集算法的性能
對於在許多項目中構建許多圖像的組織，刪除舊的，未使用的圖像和標籤很重要。容器註冊表垃圾回收需要很長時間才能運行，並且在此過程中會低效地消耗資源。這使得具有大型註冊表的實例難以運行垃圾收集，並導致存儲成本增加。
在GitLab 12.8中，對於使用S3進行存儲的實例，垃圾收集的性能有了顯著改善。這些改進優化了算法的mark和sweep階段。通過對15,000張圖片的測試，mark階段從25分鐘變為90秒。sweep階段從20分鐘變為3秒。
Git v2 支持
通過HTTP啟用了對Git協議v2的支持。它先前在GitLab 11.4中支持，但由於Git 2.21之前的Git版本中的安全問題而被禁用。
開發人員每天要多次獲取引用，以檢查當前分支是否位於遠程分支之後。Git協議v2是對Git 有線協議的主要更新，該協議定義了客戶端（計算機）和服務器（GitLab）之間如何通信克隆，獲取和推送。新的Wire協議提高了fetch命令的性能，並支持將來的協議改進。
此前，對提取命令的所有響應都包括存儲庫中所有引用的列表。例如，獲取單個分支的更新（例如git fetch origin master）還將檢索所有引用的完整列表。對於大型項目，這可能會超過100,000個引用和數十兆字節的數據。
Git 2.18.0支持新增加了對Git v2的支持。要啟用v2，請運行git config --global protocol.version 2。
在垃圾收集期間清理損壞的Docker清單
在運行垃圾回收以刪除舊的未使用的映像時，用戶經常會遇到一個問題，即由於Docker清單損壞而導致進程失敗。要解決此問題，管理員必須手動從對象存儲中刪除損壞的文件，這很慢且存在風險。
在12.8中，任何損壞的清單都將作為垃圾收集過程的一部分被刪除。如果在垃圾回收期間發現一個錯誤的鏈接文件（大小為零字節或校驗和無效），而不是停止垃圾回收器，它將記錄一條警告消息並忽略它。如果與無效鏈接文件相關的sweepBlob與另一個有效鏈接文件沒有關聯，則這些Blob 將在階段中刪除。此更新使垃圾收集過程更加可靠和高效。
功能棄用
Auto DevOps Auto Deploy設置值已棄用
Kubernetes 1.16刪除了一些API，Auto DevOps中deploymentApiVersion設置的默認值extensions/v1beta1已經去除。
默認值將在GitLab 13.0中d更改為apps/v1。
變化日期： 2020年5月17日
GitLab 13.0中移除對PostgreSQL 9.6和10.x兼容
為了利用PostgreSQL 11中改進的性能和功能（例如分區），計劃在GitLab 13.0中要求PostgreSQL的最低版本為11。為此，12.8中開始支持PostgreSQL 11，並在Omnibus 版本中自帶PostgreSQL 11。目前還支持和打包了PostgreSQL 9.6和10.x，將在GitLab 13.0中刪除。
通過要求最低版本的PostgreSQL 11，可以使用其最新功能，而無需維護多套代碼版本。未來，Gitlab將保持每年一次的PostgreSQL升級節奏，要求的最低版和最新版本差不超過二。
變化日期： 2020年5月22日
向後移植os.Expand
GitLab Runner 13.0中，Go v1.10.8將刪除向後移植的os.Expand。以包括Go v1.11中引入的行為更改。
刪除日期： 2020年5月22日
手動解析DockerService
GitLab Runner 13.0中，將恢復為使用默認的TOML解析器。
變化日期：2020年5月22日
舊版構建目錄緩存功能標誌。
GitLab Runner 13.0中，將刪除11.10中引入的舊版構建目錄緩存功能標誌。
刪除日期： 2020年5月22日
Docker服務標誌註冊命令
GitLab Runner 13.0中，將支持用於為使用字符串數組定義Docker服務的舊配置結構。
變化日期： 2020年5月22日
Shell執行程序舊式進程終止功能標誌
GitLab Runner 13.0中，將刪
FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL對shell執行程序標誌的支持。
刪除日期： 2020年5月22日
刪除/debug/jobs/list?v=1接口
GitLab Runner 13.0中，將刪除/debug/jobs/list?v=1用於監視的接口。用/debug/jobs/list?v=2取代。
變化日期： 2020年5月22日
Windows批處理命令cmd
在GitLab 11.11中，將不建議將Windows Batch執行程序用於GitLab Runner。在GitLab 13.0中將刪除對Windows Batch的支持。
變化日期： 2020年5月22日
Python依賴項掃描基礎鏡像將不再使用Alpine
下一個小版本中將使用Debian slim作為Python依賴關係掃描的基礎圖像。通過更改基礎鏡像來增強對Python的支持。改用Debian slim後，掃描儀將支持更多的Python項目。
由於鏡像不再是Alpine Linux，因此apk add 在掃描之前使用Alpine特定命令命令（僅適用於已禁用Docker-in-Docker的用戶）或在構建正式Docker鏡像變體時必須進行修改。
變化日期： 2020年3月22日
對於安全性的嚴重性和可信度，不建議使用"未定義"
Gitlab UX團隊發現，用於"嚴重性和信心"的術語相似但不相同，這導致了很多混亂。在Secure中，將棄用undefinedSecurity Reports（JSON）和漏洞API中的Severity和Confidence屬性。
如果正在漏洞API中搜索或期望undefined作為過濾器值，則可以改用。
變化日期： 2020年5月22日
GitLab 13.0將許可證管理重命名為許可證合規性
GitLab許可管理在GitLab 13.0中將重命名為GitLab許可合規性。經過用戶和分析師的審查，確定這個新名稱可以更好地表明該功能的用途，並與現有市場術語保持一致，並減少與GitLab訂閱許可功能的混淆。可以在Epic中將許可證管理重命名為許可證合規性中找到有關此問題的研究和工作。作為許可證合規性一部分進行的項目分析將稱為許可證掃描。
從GitLab 12.8開始，那些使用許可證合規性提供的模板的人可能會開始使用
License-Scanning.gitlab-ci.yml而不是
License-Management.gitlab-ci.yml。GitLab 13.0版本的發佈後，
License-Management.gitlab-ci.yml將被刪除，並且使用License Compliance。供應商模板的GitLab 13.0或更高版本上的所有用戶都必須使用
License-Scanning.gitlab-ci.yml。
如果直接引用作為"許可證合規性"的一部分運行的"許可證掃描"的結果，則還需要使用新的報告類型
artifacts:reports:license_scanning代替
artifacts:reports:license_management。
變化日期： 2020年5月22日
版本更新
Omnibus安裝版本升級
Omnibus安裝的自建實例可以使用包管理器一鍵升級。
對於CentOS可以使用
sudo yum updata/install gitlab-ce
會自動完成升級過程。
docker版本升級
先停止和刪除舊的容器
sudo docker stop gitlab
sudo docker rm gitlab
拉取gitlab官方最新的鏡像：
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
