GitLab CICD 部署与 GitLab 环境分支流程

Question

我正在尝试为基于 docker 的 web 应用程序项目设置 gitlab cicd 管道流。 这个想法是使用gitlab 环境分支流，使开发的代码向 prod 环境冒泡，并在互联网上公开。

从master分支，我在专用分支上开发了一个特性，然后我打开一个合并请求到master 。 如果测试通过并且合并请求被接受，则特定作业会为我的应用程序创建一个带有构建标记的 docker 映像，该映像存储在项目容器注册表中。 这是通过使用kaniko创建一个带有latest和CI_COMMIT_SHORT_SHA标记的图像的作业来完成的，以确保图像的可再现性。

然后，将合并请求打开到staging中，以将最新的标记图像部署到 staging 中。 如果一切顺利并且我随后想部署到 prod 中，我git 用语义版本控制（即 vX.YZ）标记当前提交。 标记过程触发了一个标记管道，我使用它从暂存图像版本中创建一个新的语义版本化图像标记，这要归功于起重机（这避免了我重建新图像）。

现在我向prod打开一个合并请求，它应该在生产中进行部署。 在这里我有一个问题。 理想情况下，恕我直言，最好使用语义版本控制标签部署图像。 这是随着时间的推移确保可重复性的最佳方式，并有助于准确了解在 prod 中运行的映像版本。 问题是 gitlab CICD 管道交替提供标签名称或分支名称。 含义：无法同时访问 git 标记名称和管道中的分支，无论其类型（分支/标记）如何。 对我来说，相反，它们都应该在两种类型的管道中都可用。

如果我有标签，我就无法知道我在哪个分支。 这可能会导致从我标记的任何地方重新部署到 prod，这可能会导致不需要的部署。 相反，如果我有分支名称，我确定我在合并到生产时正在部署，但我无法通过 git 标签部署我想要的映像版本。 是的，我可以使用 COMMIT_SHORT_SHA，但这使得在注册表中生成语义版本标记图像毫无用处，这将是准确了解部署到 prod 中的最佳选择。

关于如何解决这个问题的任何想法？ 谢谢！

Answer 1

如果我正确理解您的问题，您希望能够在管道中同时获得提交标签和分支名称。 您可以使用CI_COMMIT_TAG作为标签并执行以下命令以获取变量 TAG_BRANCH TAG_BRANCH=$(git branch --contains tags/CI_COMMIT_TAG)中的分支名称。