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主要功能合併請求的審閱者要求小夥伴們幫你程式碼應該開發的日常工作，但這通常很繁瑣。要求進行審查之類的簡單任務可能會導致混亂。例如，應該怎麼開始？一封郵件？評論？聊天訊息？沒有正式的流程，評論可能會不一致並且難以跟蹤。此前，一種選擇透過合併請求中分配審閱者。即使具有這種形式，作者和審閱者都出現在參與者中，這使得其他團隊成員很難知道誰在做什麼。
未來的迭代將包括顯示合併請求中最相關的審閱者，以及使審閱者成為中心的簡化的合併請求批准流程。
發生故障時自動回滾（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的專案。
選擇直接從合併請求中一次顯示一個檔案合併請求審閱是確保貢獻者提供高質量程式碼的一項重要任務，因為這是作者與審閱者之間大部分溝通的地方。但是，隨著合併請求變得更大並且涉及更多檔案，合併請求差異的導航和效能可能會變得困難。
單個檔案模式提供了更整潔的工作空間，並增強了審閱者對單個檔案的關注，同時提高了合併請求差異的效能和導航。
檢視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-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。新增加的功能：
使用主機別名為Kubernetes支援額外的主機。
支援Kubernetes Pod DNS配置。
提高高速網路上的快取上傳速度。
新增對Windows Server 2004（半年發行版）的支援。
將GitLab Runner Docker映象釋出到Amazon Elastic Container Registry。
從FF_GITLAB_REGISTRY_HELPER_IMAGE功能標記後面的GitLab.com容器登錄檔而不是Docker Hub提取幫助程式映象。
TSL協議要求最低版本為TLS 1.2。
basefolder建立VirtualBox VM時允許指定。
清除機密時出錯：資源名稱可能不為空。
當預設存檔程式提取檔案時，FastZip存檔會有警告。
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，從而可以直接連結到任何漏洞的詳細資訊。儘管在可見性和一致性方面有了很大的改進，但仍然必須複製貼上問題和Epic中的漏洞作為手動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速率限制導致管道失敗；
最近的問題/Epic/ MR自動完成建議未顯示標題完全相同的專案；
當專案搜尋成功時，全域性搜尋找不到結果；
全域性搜尋匹配項在暗模式下很難閱讀；
無法在Geo Secondary上列出容器儲存庫登錄檔和影象；
replicate-geo-database 全新的二次安裝失敗；
選擇問題型別並關閉下拉選單時，問題會立即提交；
當路線圖上的Epic少於1000個時，錯誤地顯示警告；
單擊側邊欄中的"編輯"標籤後，下拉菜單隻有在您單擊下拉選單後才會開啟；
過期的迭代不會出現在邊欄中；
CentOS 6於2020年11月停產。GitLab 13.6是在CentOS 6上部署GitLab的最後一個受支援版本。建議升級到CentOS 7或8。
目前，GitLab支援：
應用程式日誌的文字，JSON和logstash日誌格式。
用於訪問日誌的文字，JSON和組合日誌格式。
將棄用logstash和組合格式，僅使用兩個選項文字（用於開發）和JSON統一應用程式和訪問日誌的格式化程式。
容器登錄檔當前支援只能用於電子郵件通知的日誌記錄Hook。
當前為Redis連線池公開的一些配置設定與基礎Redis客戶端繫結，並且在替代庫中沒有等效設定。在開始改進Redis整合（例如增加對Sentinel的支援）的工作時，決定開始著手嘗試以功能更豐富的替代方法來替換當前的Redis客戶端依賴項，從而更好地為其提供支援。為此，需要替換繫結到當前客戶端庫的當前Redis池配置設定。打算：
新增redis.pool.size（最大連線數），redis.pool.minidle（最小空閒連線數）和redis.pool.maxlifetime（可以重用連線的最大時間）設定。
出於安全性考慮，由於GitLab不再支援TLS 1.0和TLS 1.1。將對當前支援1.0（預設），1.1、1.2和1.3的GitLab容器登錄檔進行同樣的操作，且預設為1.0。
在GitLab 14.0中棄用一鍵式GitLab託管應用程式變化日期：2020年12月22日
在GitLab 13.7中，棄用一鍵安裝GitLab託管應用程式。儘管對從GitLab部署到Kubernetes的入門非常容易，但是社群的總體反饋是，它們對於實際的Kubernetes應用程式不夠靈活或不可定製。未來方向將集中在透過GitLab CI/CD在Kubernetes上安裝應用程式，以便在易用性與擴充套件自定義之間取得更好的平衡。
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輔助資料庫並重新同步。
在GitLab Runner 13.1（版本3376）中，介紹了Shell執行器sigterm，然後介紹sigkill了該過程。我們還引入了一個新的功能標誌，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此您可以使用以前的過程終止序列。
在GitLab runner13.2翻譯step_script到build_script被新增到自定義執行。在14.0中，該build_script階段將替換為step_script。
在GitLab 13.7和更高版本中，GitLab需要Git 2.29或更高版本。Omnibus GitLab安裝包括Git 2.29。從源安裝必須手動升級。
Gitlab正在透過HTTP介面整合與Opsgenie和其他警報工具進行更深入的整合，以便可以在GitLab介面中檢視警報。因此，在2021年1月22日釋出13.8版之後，將不建議使用警報列表中指向Opsgenie的上一個連結。
依賴性掃描不再支援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）或更早的版本。
自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.ymlbandit-sast:variables:SAST_ANALYZER_IMAGE: "$SECURE_ANALYZERS_PREFIX/bandit:2.10.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 -d在升級到13.7的過程中，GitLab Helm Chart部署將短暫中斷。這是由於對Webservice部署的管理方式進行了更改，從而導致較舊的部署在建立新的部署之前被銷燬。當圖表移至此新方法時，只會在此版本中發生。
對於GitLabHelm Chart的使用者，已添加了一個新的秘密以支援加密的憑據。如果禁用了共享機密Chart，則在GitLab 14.0需要手動建立。