问题描述
在构建自己的项目组合时，用户希望展示所有他所了解的最佳实践，包括单元测试和持续集成。原始项目是用C++开始的，利用buddy.works进行编译和测试。尽管管理CMakeLists很麻烦，但为了更好的效果，他忍受了这一切。
然而，不久后他意识到Qt更适合他的目标。作为一个非商业性开源项目，他可以免费使用Qt Creator。然而，buddy.works（以及几乎所有其他免费的CI工具）只允许使用裸露的GCC构建环境。在他的情况下，他需要一个完全配置好的Qt环境，就像在安装IDE时一样，还需要包括Android SDK和NDK。
他注意到buddy.works允许在”private container”中运行命令，但他不确定是否可以自己构建一个容器（如果他确定这会起作用，他会开始研究这个）。
他认为最安全的选择可能是租用Amazon EC2实例，在上面安装所有需要的内容（Qt、SDK、Jenkins），并配置它与GitHub或Bitbucket进行通信，但这会花费一些费用（他无法确定具体数额）。他预计CI过程每周只运行三次，平均构建时间最多半小时。他还喜欢自述文件中的绿色构建徽章的想法，这是buddy.works提供的功能，在EC2实例关机后可能更难实现（如果他购买一个每天启动、运行CI然后关闭的实例的话）。然而，他非常希望能有一个免费的替代方案。
解决方案
以下是一些解决方案，可以根据实际情况进行选择。
方案1：自定义Docker容器
Docker容器技术的主要优势之一是标准化：可以在开发过程中或CI/CD流水线执行期间，轻松复制相同的环境，无论是在个人计算机上还是CI机器上。
对于不包含在服务提供商默认容器映像中的操作系统级依赖项（例如库和工具集），构建和使用自定义容器是一种相当标准的方法。根据提供商的不同，您可能对使用的基础映像的选择有一定的限制。
如果您的CI/CD提供商接受自定义构建的容器（并不是所有提供商都接受，至少目前不是所有），并且您可以满足其自定义容器的限制（如果有的话），那么为您的情况构建自定义容器将是一个有价值的投资。这不仅适用于CI执行，甚至适用于开发您的应用程序，最终还可以展示容器技术作为开发技术本身。
方案2：使用Jenkins和GitLab
您可以结合Jenkins和GitLab来实现您的持续集成。两者都是免费的。至于Qt项目，您可以使用sh或bat步骤来从构建作业内部运行qmake或cmake。
还有很多插件可以扩展Jenkins并将其与GitLab集成。这包括一些插件，允许您在推送到特定分支时触发构建，甚至生成您想要的构建徽章。详情请参见：Embeddable Build Status Plugin。
请注意，这些方案可能会受到不同CI/CD提供商的限制和支持程度的影响。在选择方案时，请仔细研究您选择的CI工具和其支持的功能。