12月22日距離平安夜還有兩天，距離新年還有一周多點，又到Gitlab發版的日子了。這次發布的版本是Gitlab 13.7，雖然和日常的功能略少點，但是也包括了45項功能和改進， 詳細的功能請和蟲蟲一道學習嘗試。
概述
增強項目管理以實現跨協作
合併請求（MR，Github中是PR）是Git生態協作交互中最重要的部分。它促進了Fork協作，支持將其與相關問題直接關聯，提供一個中心位置，通過commit進行交流，代碼更改建議，執行代碼審查等。在新版本中，Gitlab添加了合併請求審閱者，功能通過使審閱更加容易和更有條理來改善代碼審閱過程，新功能可以快速找出合併請求中涉及的人員，或請求進行正式審查向他們發送通知。
工作流中的上下文切換和手動任務阻礙了在組和項目之間進行有效協作的能力。花費更少的時間來開發有價值的功能，而花費更多的時間來管理項目，這就是為什麼能夠快速採取行動克隆問題的對簡化敏捷規劃和項目管理如此重要的原因。
在項目上進行協作並快速迭代以開發應用程式，這樣需要能夠快速確定問題的重要性順序，確定所有阻止者，並使用該信息確定下一步的工作重點。現在，新版中可以按阻止者對問題進行排序，以快速找出哪些問題阻止了其他問題的進展，以及輕鬆按問題列表中阻止者的數量進行排序。
改進的發布自動化和部署靈活性
用戶需要靈活性來控制如何定期組織，自動化和部署應用程式。可靠且頻繁地部署應用程式可以更快地將價值帶到客戶手中。
為了改善GitLab自動發布的方式，新添加了在發生故障時自動回滾的功能。此功能會自動將失敗的部署恢復為上一次成功的部署，並發送自動通知以提醒用戶當前狀態。無需手動進行任何更改，並且可以確信在嘗試解決問題時，潛在的問題不會導致停機或加劇。
發生故障時自動回滾非常適合進行一項改進，即能夠在「環境」頁面中查看部署狀態。現在，可以輕鬆找到部署狀態並確定需要執行的操作，例如停止或回滾部署。
更可靠，高效的軟體包和依賴項管理
用戶的工作流程取決於多種程式語言，二進位文件，集成和工件，這些都是開發過程的重要輸入或輸出。為了可以更有效地管理軟體包和依賴項，從而減少浪費的開發時間，並且出於效率考慮，新添加了快速查找和查看通用軟體包的選項。還對GitLab的依賴項代理進行了改進，已經在GitLab 13.6的Core中提供。
現在，可以避免Docker速率限制，並使用Dependency Proxy來加快管道的速度，以確保在緩存DockerHub上託管的容器鏡像時對可靠性的信心並提高效率。
社區中許多人都希望看到的另一個改進是，Dependency Proxy現在可以與私有項目一起使用，並解決了那些使私有項目的人無法利用此功能的限制。
最後但並非最不重要的一點是，支持預定義變量與依賴項代理一起使用，而不必依賴於自己定義的變量或gitlab.ci-yml文件中的硬編碼值。這提供了一種更可擴展且更有效的方式來開始代理和緩存鏡像。
GitLab 13.7主要功能
合併請求的審閱者
要求小夥伴們幫你代碼應該開發的日常工作，但這通常很繁瑣。要求進行審查之類的簡單任務可能會導致混亂。例如，應該怎麼開始？一封郵件？評論？聊天消息？沒有正式的流程，評論可能會不一致並且難以跟蹤。此前，一種選擇通過合併請求中分配審閱者。即使具有這種形式，作者和審閱者都出現在參與者中，這使得其他團隊成員很難知道誰在做什麼。
GitLab 13.7引入了用於合併請求的審閱者，允許作者向某發出請求審閱。新的「審閱者」欄位允許以與參與者相似的方式將用戶指定為審閱者。審閱者收到通知，邀請他們審閱合併請求。這提供了一個請求審閱的正式流程，並闡明了合併請求中每個用戶的角色。
未來的迭代將包括顯示合併請求中最相關的審閱者，以及使審閱者成為中心的簡化的合併請求批准流程。
發生故障時自動回滾（ULTIMATE）
如果部署中遇到嚴重問題，則通常需要花費很長時間來進行手動操作以解決該問題，並且會導致影響用戶的生產質量下降。現在，可以利用自動回滾機制，將部署還原為上一次成功的部署。此外，當GitLab在生產中發現問題時，它會自動以發出告警通知。這使高枕無憂，並有寶貴的開發時間來調試，研究和解決問題，而不會造成停機。
快速克隆問題
為了使生成類似問題的效率更高，問題現在支持/clone快速行動，該行動可以在同一項目中創建具有相同標題，描述和元數據的新問題。該/clone行動迅速取代了較為繁瑣的過程，它涉及多個步驟來創建一個問題，複製源問題的ID或路徑，並使用copy_meta快速行動。
默認情況下，問題被克隆到同一項目中，並不包括評論，但是也可以在克隆時更改默認行為。
Red Hat OpenShift GitLab Runner鏡像
今天可用的是Red Hat OpenShift容器平臺的GitLab Runner容器鏡像。要在OpenShift上安裝運行程序，可以使用新的GitLab Runner操作程序，該程序可從Red Hat的Operator Hub的beta通道中獲得。該Operators是一個Web控制臺，OpenShift群集管理員可以發現並選擇要在其群集上安裝的Operators。默認情況下，Operator Hub部署在OpenShift容器平臺中。預計在2021年初將GitLab Runner Operators在穩定版發布，並向GA進行過渡擴展。
在「環境」頁面上顯示部署狀態
以前，在查看「環境」頁面時，無法知道正在進行部署。通過現在可以看到部署狀態和警報，「環境」頁面將指示可以根據部署狀態（成功，失敗或進行中）採取何種操作。例如，可能想停止當前正在進行的部署，或回滾完成的部署。
通過UI設置部署流量權重（PREMIUM及以上）
在GitLab 13.7中，可以直接從用戶界面中的部署板更改canary權重。可以直接從gitlab-ci.ymlAPI和API中更改canary的權重，但是在UI中，可以查看部署並直接從Deploy Boards縮放Pod。這樣可以更好地控制手動或定時增量部署，並可以更好地緩解風險。
API支持部署頻率（ULTIMATE）
作為首次在GitLab中支持DORA4指標的迭代的一部分，此版本增加了對項目級別部署頻率的API支持。這樣，可以隨著時間的推移監視部署的效率，輕鬆找到瓶頸，並在必要時快速採取糾正措施。
在一個項目中支持多個清單文件（PREMIUM及以上）
在以前的GitLab版本中，GitLab Kubernetes代理要求用戶將所有Kubernetes資源收集到一個清單文件中。在新版本的GitLab中，GitLab Kubernetes代理可以從項目中的指定目錄中遞歸地獲取Kubernetes清單。平臺工程師可以使用一個存儲庫從一個地方管理不同的集群，並且可以使用一個代理描述大型部署。
需求導入（ULTIMATE）
將所有需求放在一個地方對於高效協作至關重要，新版本中在可以從CSV（逗號分隔值）文件中導入需求。
此功能將使整個團隊可以根據GitLab的要求進行協作，但仍可以使輕鬆地與客戶，供應商和外部組織進行交互。
告警工具與多個HTTP接口集成（PREMIUM及以上）
告警集成是事件管理工作流程中的關鍵部分，這就是為什麼用戶和團隊具有對終結點和身份驗證令牌的精細控制非常重要的原因。用戶想要做的就是通過重置單個身份驗證令牌來消除所有告警。為每個監視工具設置一個HTTP接口，使團隊可以分別管理每個工具，而不會影響其他工具的告警。
DevOps的使用報告（ULTIMATE）
DevOps Adoption顯示組織中的哪些團隊正在使用GitLab問題，合併請求，批准，運行程序，管道，部署和掃描。使用新的細分功能將GitLab組分組為對組織有意義的邏輯業務部門，以便可以輕鬆比較不同組之間的GitLab採用情況。
驗證用戶是否從GitLab獲得了預期的投資回報。
確定在採用GitLab方面滯後的特定人群，以便可以在他們的DevOps旅程中提供幫助。
確定採用了特定功能（例如管道）的小組，並可以向有興趣使用這些功能的其他小組提供提示。
改進了用於項目創建的UI
改進的用於添加項目的用戶界面使用戶可以更輕鬆地選擇創建空白項目，從模板啟動項目，導入現有項目以及為外部存儲庫創建僅CI/CD的項目。
選擇直接從合併請求中一次顯示一個文件
合併請求審閱是確保貢獻者提供高質量代碼的一項重要任務，因為這是作者與審閱者之間大部分溝通的地方。但是，隨著合併請求變得更大並且涉及更多文件，合併請求差異的導航和性能可能會變得困難。
GitLab 13.7引入了在合併請求視圖中一次顯示一個文件的選項。導航到合併請求的「更改」標籤時，點擊齒輪圖標並選中一次顯示一個文件框。這將一次顯示一個文件，並使「上一個」和「下一個」按鈕在文件之間導航。
單個文件模式提供了更整潔的工作空間，並增強了審閱者對單個文件的關注，同時提高了合併請求差異的性能和導航。
查看VS Code中的合併請求更改
在VS Code中檢查合併請求時，輕鬆引用更改通常需要籤出分支，然後嘗試確定該分支與合併目標之間的差異。
在GitLab Workflow 3.7.0版本中，合併請求更改可直接在VS Code中獲得。這樣可以快速查看項目中合併請求的更改。
通過子管道改進工件下載
以前，將工件從父管道下載到子管道並不總是提供所需的工件。如果兩個父管道同時運行，則子管道可能會意外地從較新的管道下載工件。
現在，可以使用新needs:pipeline語法來告訴子管道確切的管道，以從中下載工件。可以使用它從父管道或同一父子管道層次結構中的其他子管道下載工件。
避免Docker速率限制並加速管道
為了更快，更可靠的構建，可以使用依賴代理來緩存Docker Hub上託管的容器鏡像。但是，當Docker開始對來自Docker Hub的拉取請求實施速率限制時，會注意到，即使從緩存中拉出鏡像，Docker也會將其計入限制。這是因為「依賴代理」僅緩存鏡像層（或Blob），而不緩存清單，清單包含有關如何構建給定圖像的信息。由於清單是必需的，因此仍然需要拉取請求。這樣，如果Docker Hub不可用，則無法拉出鏡像。
向前，依賴代理將緩存鏡像的層和清單。因此，第一次拉取alpine:latest，該鏡像將被添加到Dependency Proxy緩存中，並且算作一次對速率限制的拉取。下次拉取時alpine:latest，即使Docker Hub不可用，也將從緩存中拉出，並且不會計算速率限制。
快速查找和查看通用軟體包
可以使用GitLab軟體包註冊表輕鬆發布通用文件，例如發行版二進位文件。但是，如果您使用Packages UI和其他軟體包管理器格式，則可能會注意到無法選擇一個選項卡來僅快速查看常規軟體包。
最近在Packages UI中添加了一個名為Generic的標籤，因此可以將視圖限制為僅適用於通用軟體包。希望這可以幫助用戶更快，更有效地查找和驗證軟體包。
對私有項目使用依賴代理
可以使用GitLab依賴關係代理從Docker Hub代理和緩存容器鏡像。直到最近，該功能僅適用於公共項目，使許多人無法使用它。
現在，可以將依賴項代理與私有項目一起使用。可以通過緩存容器鏡像以備將來使用，從而減少對Docker Hub的依賴。由於Dependency Proxy將Docker鏡像存儲在與組關聯的空間中，因此必須使用GitLab用戶名和密碼或使用範圍至少設置為的個人訪問令牌進行身份驗證read_registry。
在外部文件中定義發布說明
如果通過項目的.gitlab-ci.yml文件在管道中創建發行版，則可能發現很難維護每個發行版的描述。在GitLab 13.7中，現在可以在原始碼控制或自動生成的文件中定義發行說明，並從中調用.gitlab-ci.yml。這樣做會將文件內容作為Markdown加載到發布說明中。版本發行更易於創建，維護和與版本控制一起使用，如果要自動生成變更日誌，則特別有用。
添加對Kubernetes版本1.17、1.18、1.19的支持
GitLab對最新Kubernetes版本的支持使可以從GitLab的Kubernetes集成中受益，例如GitLab Kubernetes代理，Auto DevOps，以及在較新的集群上託管應用程式。GitLab增加了對Kubernetes版本1.17、1.18和1.19的官方支持。
Geo支持複製版本控制片段（PREMIUM及以上）
Geo現在支持將Versioned Snippets複製到輔助節點，允許分布式團隊從最近的Geo節點訪問它們，從而減少了延遲並改善了整體用戶體驗。此外，在故障轉移到該輔助節點時，還可以從輔助節點還原該數據。
成員MVC的組Webhooks（STARTER及以上）
GitLab使您更容易使用一個Webhook構建用戶管理自動化，該Webhook是在將新成員添加到組中時觸發的。以前，必須運行REST調用來標識新的組成員，這會給GitLab實例帶來不必要的性能負載。
改進的組成員列表過濾和排序
通過新的過濾和排序體驗來改進組成員列表，使組管理員可以快速找到其需要的成員信息。例如，按「上次登錄」排序可用於查找最近未訪問過GitLab的用戶並協助許可管理活動。
在Service Desk中使用自定義電子郵件地址
GitLab服務臺的電子郵件地址很難記住，因此用戶難以使用。通過引入可配置的電子郵件地址，現在可以選擇對企業標識有意義的地址後綴，並使用戶更容易記住。這是GitLab採取的又一個步驟，為用戶提供最優質的支持。
區分格式更改和通過靜態網站編輯器進行的編輯
靜態站點編輯器為Markdown內容提供了直觀，熟悉的所見即所得編輯模式。為了確保格式一致的Markdown輸出，WYSIWYG編輯器會自動重新設置頁面內容的格式，以匹配Markdown解析器中定義的樣式約定。這甚至在開始編輯之前就完全在後臺發生。但是，這些格式更改是在內容編輯的同時提交的。如果正在編輯的頁面沒有遵循相同的樣式約定，則結果合併請求的審閱者可能很難區分手動更改和自動格式設置。
從GitLab 13.7開始，靜態站點編輯器將自動修復Markdown語法中的不一致之處，並將所有必要的格式更改提交到新分支。完成編輯後，「發布」按鈕將創建一個單獨的提交，其中只包含用戶更改。這可以為審閱者節省時間，使他們不必專注於語法更改，而可以專注於內容。
手動運行管道時的預填充變量
以前，當需要手動運行管道時，需要了解相關變量，然後在「運行管道」頁面上輸入它們。如果要輸入許多鍵值對，這可能會很乏味且容易出錯。現在，「運行管道」表單將根據.gitlab-ci.yml文件中的變量定義為管道生成預填充的變量，從而使此過程更加高效。
使用CI/CD構建的軟體包始終顯示構建信息
如果一直在將軟體包發布到Package Registry，則可能已經注意到，使用GitLab CI/CD構建的軟體包並不總是顯示負責創建或更新軟體包的提交和管道。出於某些原因可能會發生這種情況。
首先，我們可能還不支持此功能，就像Composer和Conan一樣。其次，對於那些已經從不同分支或提交更新同一版本的軟體包的人來說，這是一個問題。可以從不同的分支和/或提交發布具有相同版本的軟體包。直到最近，UI仍僅顯示第一個部署，而未包含任何更新。此外，詳細信息頁面顯示了創建軟體包的分支，而不是最近的提交。結果，必須嘗試通過查看提交歷史記錄來查找此信息，這不是很有效。
展望未來，使用GitLab CI/CD創建或更新的任何軟體包都將在「軟體包」用戶界面中顯示提交和管道信息。為避免性能或UX問題，將僅顯示軟體包的五個更新。在13.8中，將創建一個設計，以幫助直觀地查看所有歷史數據。同時，可以使用Packages API查看給定軟體包的整個構建歷史記錄。
將預定義變量與依賴代理一起使用
通過從Docker Hub代理和緩存容器鏡像，Dependency Proxy可以幫助提高管道的性能。即使打算將代理與CI/CD一起大量使用，但要使用該功能，也必須在文件中定義自己的變量或硬編碼值gitlab.ci-yml。這使個人難以上手，並使其無法成為可伸縮的解決方案，尤其是對於具有許多不同組和項目的組織而言。
未來，可以使用預定義的環境變量作為使用依賴代理的直觀方法。支持以下變量：
CI_DEPENDENCY_PROXY_USER：CI用戶，用於登錄到依賴代理。
CI_DEPENDENCY_PROXY_PASSWORD：用於登錄依賴代理的CI密碼。
CI_DEPENDENCY_PROXY_SERVER：用於登錄依賴代理的伺服器。
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX：用於通過依賴代理獲取鏡像的鏡像前綴。
查看在fork項目和父項目中運行哪些提交和管道
在GitLab 13.3中可以使用父項目的開發人員來創建派生項目中合併請求的管道。但是，沒有辦法知道管道運行的上下文。
在新版本中，現在可以查看在派生項目與父項目中運行了哪些提交和管道。分叉的提交具有唯一的徽章和工具提示，可讓用戶知道它們是從分叉的合併請求中運行的。這使用戶很容易了解管道運行的上下文，從而無需更詳細地調查起源。
PostgreSQL 12是新安裝的默認設置
從GitLab 13.3開始，PostgreSQL 12已成為Omnibus軟體包以及我們的Helm Chart的可選加入選項。PostgreSQL 12提供了顯著的索引編制和分區優勢，以及更廣泛的性能改進。
在GitLab 13.7中，新安裝的GitLab將從13.7開始默認為PostgreSQL 12。要手動升級，請運行gitlab-ctl pg-upgrade。
在使用Patroni進行升級之前，多節點資料庫實例將需要從repmgr切換到Patroni。然後可以更新Geo輔助資料庫並重新同步。
Gitlab Runner 13.7
今天同期還將發布了GitLab Runner 13.7。新增加的功能：
能夠刪除umask 0000使用GitLab Runner Docker執行程序執行的作業。
使用主機別名為Kubernetes支持額外的主機。
支持Kubernetes Pod DNS配置。
提高高速網絡上的緩存上傳速度。
添加對Windows Server 2004（半年發行版）的支持。
從Docker Hub中刪除對Kubernetes初始化容器的依賴。
將GitLab Runner Docker鏡像發布到Amazon Elastic Container Registry。
從FF_GITLAB_REGISTRY_HELPER_IMAGE功能標記後面的GitLab.com容器註冊表而不是Docker Hub提取幫助程序鏡像。
TSL協議要求最低版本為TLS 1.2。
basefolder創建VirtualBox VM時允許指定。
當GitLab Runner與systemd一起使用時刪除重複的日誌。
清除機密時出錯：資源名稱可能不為空。
當默認存檔程序提取文件時，FastZip存檔會有警告。
刪除構建目錄中的.git/onfig.lock。
GitLab Helm chart改進
由於更改了Webservice部署的管理方式，因此通過Helm Chart部署的GitLab實例將在此升級期間短暫中斷。
現在，可以按路徑劃分GitLab Webservice Chart的不同部署之間的流量，從而可以劃分工作負載。
nginx已更新為v0.41.2，是重大更新。由於上遊Pod參數更改，當基礎Pod重新啟動時，可能會發生短暫中斷。
registry已更新至2.12.0-gitlab，gitlab-kas至13.7.0，gitlab-runner圖表至0.23.0，gitlab-exporter至7.1.2。
現在可以使用以下terminationGracePeriodSeconds命令配置NGINX的終止寬限期。
GitLab Praefect現在支持TLS加密。
Omnibus的改進
現在，ARM64軟體包可用於CentOS 8。
LDAP憑證現在可以被加密。
Pages現在支持基於PROXYv2協議的HTTPS。
registry已經更新到2.12.0-gitlab，consul到1.6.6，grafana7.3.3，prometheus至2.22.2，並libjpeg-turbo到2.0.6。
GitLab 13.7包含Mattermost 5.29，它是開源的Slack替代品，其最新版本包括Mattermost Omnibus的一般可用性以及更多功能。還包括安全更新，建議從早期版本進行升級。
安全和合規性審計
限制預配置帳戶的項目和組創建（PREMIUM及以上）
為了減少意外暴露智慧財產權的風險，GitLab管理員現在可以更好地控制由其小組的SAML或SCIM集成提供的帳戶。在這些控制項的第一次迭代中，管理員可以阻止其用戶在尚不屬於他們的組之外創建組或項目。
按問題阻止的數量對問題進行排序（STARTER及以上）
在GitLab中確定問題列表的優先級時，通常重要的是確定關鍵路徑以及問題是否正在阻止其他問題。
使用當前的問題列表，無法查看哪些問題正在阻止其他問題。唯一的方法是打開每個阻止程序，然後在問題說明下方查看阻止程序列表，這是一項非常耗時的任務！
從13.7開始，可以使用過濾器對任何問題列表進行「阻止」，然後會看到一個按阻止者數量排序的列表。
改進了對SAST分析儀的多項目支持
GitLab安全掃描會自動檢測代碼語言並運行適當的分析器。使用monorepos，微服務和多項目的存儲庫，單個存儲庫中可以存在多個項目。以前，安全工具只能檢測存儲庫中的單個項目。在此版本中，我們的SAST分析儀現在可以智能地檢測多項目存儲庫，並為每個項目運行適當的掃描儀並報告漏洞。對於具有多項目存儲庫的用戶，這將使用戶更輕鬆，更簡化地利用安全工具。未來的更新將進一步改善這些類型項目的儀錶板和報告功能。
支持加密的LDAP憑證
GitLab使用統一的配置文件，例如gitlab.rb在Omnibus GitLab中，這使跨所有捆綁服務的配置變得容易。此配置文件中包含一些機密，比如用於驗證LDAP伺服器的憑據。雖然訪問此文件確實需要提升的特權，但是最佳實踐是將機密與配置分開。
Omnibus GitLab和Source安裝現在支持加密的憑據，支持的第一個憑據是LDAP。這降低了GitLab配置文件的敏感性，還有助於達到客戶合規性要求。
改善MR體驗以進行安全掃描（PREMIUM及以上）
現在，SAST和秘密檢測可用於所有使用級別，改善了所有GitLab用戶在合併請求中與安全掃描結果進行交互的體驗，從而使任何人都可以更輕鬆地訪問安全掃描結果。以前的安全掃描結果只能在「管道概述」頁面上訪問，並且必須知道在哪裡可以找到它們。現在，所有合併請求將顯示是否已運行安全掃描，並幫助用戶找到作業工件。此更改不會更改Ultimate用戶的MR體驗。
漏洞的特殊參考（ULTIMATE）
Gitlab在12.10中將漏洞作為一流對象引入。成為一流對象意味著每個對象都有一個唯一的URL，從而可以直接連結到任何漏洞的詳細信息。儘管在可見性和一致性方面有了很大的改進，但仍然必須複製粘貼問題和史詩中的漏洞作為手動Markdown連結。與共享其他對象（例如問題）相比，這使得在GitLab其他區域中共享和引用漏洞更加麻煩且效率較低。
現在可以通過特殊引用連結漏洞。它們是第一個使用新[object_type:ID]語法的語言，該語法最終將擴展到其他現有引用。現在，可以從通常可以使用特殊引用（例如問題或合併請求注釋）的任何地方快速插入指向漏洞的連結。例如，鍵入[vulnerability:123]問題注釋以在同一項目中插入ID為123的漏洞的連結。還可以在ID前面加上名稱空間或項目，以引用當前項目上下文之外的漏洞。
生成代碼質量的HTML報告
代碼質量報告為提供了有關在當前分支上發現的有關代碼質量違規的各種信息，但是它們的格式不容易閱讀。
現在，此報告已作為.html文件提供，因此可以更輕鬆地查看項目中的代碼質量違規並確定影響。
性能改進
使用負載平衡器時，資料庫查詢速度更快
許多資料庫查詢會重複幾次，並且可以緩存以提高整體性能。對於GitLab，大約所有查詢的10%可以被緩存。在GitLab 13.7中，當使用資料庫負載平衡時，Gitlab啟用了資料庫查詢緩存，從而顯著提高了整體性能。在GitLab.com上，這意味著每分鐘緩存約700,000個查詢，並將總請求時間縮短多達10%。
對於執行100個以上查詢的請求，將請求持續時間縮短了11-31％，並將所有在資料庫副本上執行的SELECT語句的30%緩存了。
GitLab 13.7中針對問題，項目，裡程碑以及其他方面還進行了性能改進。包括：
漏洞報告加載更快；
漏洞狀態和嚴重性計數更快地加載；
測試報告作業頁面更快，響應速度更快；
活動用戶計數許可證查詢得到改進；
通過逐漸加載較大的批次來加快MR差異；
Bug修復
GitLab 13.7中一些值得注意的錯誤修復有：
漏洞標識符即使沒有連結也顯示為連結；
在漏洞報告中，項目選擇器未顯示組中的所有項目；
組安全儀錶板顯示不正確的漏洞計數；
npm包API速率限制導致管道失敗；
NuGet包API速率限制導致管道失敗；
最近的問題/史詩/ MR自動完成建議未顯示標題完全相同的項目；
當項目搜索成功時，全局搜索找不到結果；
全局搜索匹配項在暗模式下很難閱讀；
無法在Geo Secondary上列出容器存儲庫註冊表和圖像；
replicate-geo-database 全新的二次安裝失敗；
選擇問題類型並關閉下拉菜單時，問題會立即提交；
當路線圖上的史詩少於1000個時，錯誤地顯示警告；
單擊泳道側邊欄中的「編輯」標籤後，下拉菜單只有在您單擊下拉菜單後才會打開；
過期的迭代不會出現在邊欄中；
功能刪除
刪除對CentOS 6支持
刪除日期：2020年12月22日
CentOS 6於2020年11月停產。GitLab 13.6是在CentOS 6上部署GitLab的最後一個受支持版本。建議升級到CentOS 7或8。
刪除容器註冊表日誌格式化程序
變化日期：2021年1月22日
目前，GitLab支持：
應用程式日誌的文本，JSON和logstash日誌格式。
用於訪問日誌的文本，JSON和組合日誌格式。
將棄用logstash和組合格式，僅使用兩個選項文本（用於開發）和JSON統一應用程式和訪問日誌的格式化程序。
刪除Container Registry日誌Hook
變化日期：2021年1月22日
容器註冊表當前支持只能用於電子郵件通知的日誌記錄Hook。
如今，基於日誌條目的警報通常由單獨的工具處理。據統計，Gitlab用戶都不依賴此功能，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（可以重用連接的最大時間）設置。
刪除Bugsnag的Container Registry支持
變化日期：2021年1月22日
Bugsnag是容器註冊表支持的錯誤報告服務之一。據所知，沒有用戶依賴此服務。為了簡化和合併受支持的錯誤報告服務，打算、刪除對Bugsnag的支持。
刪除對NewRelic的Container Registry支持
變化日期：2021年1月22日
NewRelic是容器註冊表支持的錯誤報告服務之一。據我們所知，沒有用戶依賴此服務。為了簡化和整合支持的錯誤報告服務，打算刪除對NewRelic的支持。
刪除對TLS 1.0和1.1 Container Registry的支持
變化日期：2021年1月22日
出於安全性考慮，由於GitLab不再支持TLS 1.0和TLS 1.1。將對當前支持1.0（默認），1.1、1.2和1.3的GitLab容器註冊表進行同樣的操作，且默認為1.0。
打算刪除對TLS 1.0和TLS 1.1的支持，並在使用它們時顯示警告日誌消息。這些版本的支持將被刪除，並且TLS 1.2將成為默認版本。
在GitLab 14.0中棄用一鍵式GitLab託管應用程式
變化日期：2020年12月22日
在GitLab 13.7中，棄用一鍵安裝GitLab託管應用程式。儘管對從GitLab部署到Kubernetes的入門非常容易，但是社區的總體反饋是，它們對於實際的Kubernetes應用程式不夠靈活或不可定製。未來方向將集中在通過GitLab CI/CD在Kubernetes上安裝應用程式，以便在易用性與擴展自定義之間取得更好的平衡。
計劃在GitLab 14.0版中完全刪除一鍵式託管應用程式。這不會影響集群中現有託管應用程式的運行方式，但是，將不再能夠通過GitLab UI更新修改那些應用程式。建議集群管理員計劃通過手動或通過CI/CD重新安裝現有的託管應用程式
刪除對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。
GitLab Runner安裝程序忽略skel目錄
變化日期：2021年6月22日
在GitLab Runner 14.0中，skel默認情況下，安裝過程將在創建用戶主目錄時忽略該目錄。
將pwsh設為新註冊的Windows Runner的默認shell
變化日期：2021年6月22日
在GitLab Runner 13.2中，PowerShell Core支持已添加到Shell執行程序中。在14.0中，pwsh它將是新註冊的Windows運行程序的默認外殼程序。Windows CMD仍可作為Windows運行程序的外殼程序選項使用。
PostgreSQL 11支持
變化日期：2021年5月22日
PostgreSQL 12將是GitLab 14.0中最低要求的版本。它為索引編制，分區和一般性能優勢提供了重大改進。
從13.7開始，新安裝的GitLab將默認為PostgreSQL 12。要手動升級，請運行gitlab-ctl pg-upgrade。
在使用Patroni進行升級之前，多節點資料庫實例將需要從repmgr切換到Patroni。然後可以更新GEO輔助資料庫並重新同步。
從包中刪除/usr/lib/gitlab-runner符號連結
刪除日期：2021年6月22日
在GitLab轉輪13.3，增加了應/user/lib/gitlab-runner/gitlab-runner到/usr/bin/gitlab-runner得符號連結從加入。在14.0中，將刪除此符號連結，並將運行器安裝在中/usr/bin/gitlab-runner。
刪除FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL功能標記
刪除日期：2021年6月22日
在GitLab Runner 13.1（版本3376）中，介紹了Shell執行器sigterm，然後介紹sigkill了該過程。我們還引入了一個新的功能標誌，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此您可以使用以前的過程終止序列。
刪除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能標誌
刪除日期：2021年6月22日
在GitLab Runner 14.0中，將刪除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能標記。
刪除Ubuntu 19.10（Eoan Ermine）軟體包
刪除日期：2021年6月22日
Ubuntu 19.10（Eoan Ermine）已於2020年7月17日星期五到期，在GitLab Runner 14.0中，我們將從軟體包分發中刪除Ubuntu 19.10（Eoan Ermine）。
刪除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聲明了一項工作。為了支持普羅米修斯規則，選擇了轉換success/failure到finished度量標準。在14.0中，我們將刪除轉換。
在自定義執行程序中刪除從step_script到build_script的翻譯
刪除日期：2021年6月22日
在GitLab runner13.2翻譯step_script到build_script被添加到自定義執行。在14.0中，該build_script階段將替換為step_script。
需要Git 2.29或更高版本
刪除日期：2020年12月22日
在GitLab 13.7和更高版本中，GitLab需要Git 2.29或更高版本。Omnibus GitLab安裝包括Git 2.29。從源安裝必須手動升級。
與Opsgenie的直接連結將被刪除
變化日期：2021年1月22日
Gitlab正在通過HTTP接口集成與Opsgenie和其他警報工具進行更深入的集成，以便可以在GitLab界面中查看警報。因此，在2021年1月22日發布13.8版之後，將不建議使用警報列表中指向Opsgenie的上一個連結。
刪除Python 2對依賴性掃描的支持
刪除日期：2021年12月15日
依賴性掃描不再支持2020年1月1日日落的Python 2（通過設置DS_PYTHON_VERSION:2）。如果需要Python 2，則需要使用容器版本v2.10.0（例如，registry.gitlab/gitlab-org/security-products/analyzers /retire.js：2.10.0）或更早的版本。
刪除對Python 2的SAST支持
刪除日期：2021年12月9日
自2020年1月1日起，Python 2便已終止生命周期（EoL）。作為維護和更新我們的基礎SAST分析器的一部分，Gitlab更新了Bandit，它放棄了對Python 2規則的支持。如果仍然需要支持Python 2應用程式，則可以覆蓋GitLab SAST CI模板以固定到支持Python 2的早期版本的Bandit。通過固定至先前的版本，將不會收到Python SAST分析器的最新更新。以下是可以放入SAST.gitlab-ci.yml模板中的替代代碼段：
include:
- template: Security/SAST.gitlab-ci.yml
bandit-sast:
variables:
SAST_ANALYZER_IMAGE: "$SECURE_ANALYZERS_PREFIX/bandit:2.10.0"
升級更新
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.7的重要說明
在升級到13.7的過程中，GitLab Helm Chart部署將短暫中斷。這是由於對Webservice部署的管理方式進行了更改，從而導致較舊的部署在創建新的部署之前被銷毀。當圖表移至此新方法時，只會在此版本中發生。
對於GitLabHelm Chart的用戶，已添加了一個新的秘密以支持加密的憑據。如果禁用了共享秘密圖表，則在需要時，需要通過GitLab 14.0手動創建此秘密。