公司的gitlab容器使用的镜像版本为14.1.2，已经是一年前的了。我是个喜新厌旧的人，所以动起了把gitlab升级到最新的念头。从官网上了解到不同版本的gitlab之间有一个升级路径。不遵循这个升级路径，出问题自己后悔去吧。对照当前的版本，我的升级路径如下图：

公司之前买了一个3年的腾讯云服务器，本着白嫖的原则，不用白不用，把公司内部的gitlab服务器迁移到腾讯云服务器上面去。本文记录一下操作步骤，以防老年痴呆。整个迁移流程其实很简单，就是先备份数据，然后在新机器上面还原数据，如图所示，以下分步骤说明。为了防止混淆，下文将公司内部的gitlab服务器称为内部服务器。

构建类型基础知识

CMake提供了几种默认的构建类型：

• Debug：没有优化并附带完整的调试信息，通常在开发和调试过程中使用。
• Release：没有调试信息，提供全面的速度优化。
• RelWithDebInfo：在某种程度上是前两者的妥协，它的目的是使性能接近于发布版，但仍允许某种程度的调试。通常会对速度进行大部分优化，但也会启用大部分调试功能。默认禁用断言。
• MinSizeRel：通常只用于有限的资源环境，如嵌入式设备。代码是针对大小而不是速度进行优化的，并且不创建调试信息。

每种构建类型都会产生一组不同的编译器和链接器标志，因此了解如何选择构建类型以及如何避免一些常见的问题是很重要的。

CMake策略可以用来控制CMake使用新版还是旧版CMake的行为。

策略控制

CMake的策略功能与cmake_minimum_required命令紧密相连，该命令不仅指定了一个项目所需的最小CMake版本，而且还将CMake的行为设置为与所给版本相匹配。然而，一个项目可能需要比cmake_minimum_required命令提供更精细的控制，cmake_policy命令就是用于对策略进行更具体的控制。最简单的形式如下：

模块是预先写好的CMake代码，通常放在一个目录中作为CMake发布的一部分。include命令可以将模块代码引入到当前作用域，语法如下：

include(module [OPTIONAL] [RESULT_VARIABLE myVar] [NO_POLICY_SCOPE])

CMake首先在变量CMAKE_MODULE_PATH定义的目录列表中按顺序搜索每个目录来查找模块文件，第一个匹配的文件将被使用。如果没有找到匹配的文件，CMake将在它自己的内部模块目录中搜索。一个常见的做法是将自己写的模块加到CMAKE_MODULE_PATH变量中，然后使用模块代码：