如何根据工作流变量部署到不同的环境?
How to deploy to different enviroments based on workflow variables?
我找到了 following proposal 并对其进行了测试(参见代码示例),但无法使其正常工作。
我们运行在Gitlab 14.3.4上,我如何确定这个版本是否可用?如果此功能不起作用,如果我有不同的 运行ners,一个用于我的产品,一个用于开发环境,我该如何部署到不同的环境?到目前为止,我为每个使用其专用标签的环境都有一个管道——因为动态标签是 .
如有任何帮助,我们将不胜感激 - 谢谢!
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_PIPELINE_SOURCE == "parent_pipeline"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: "$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS"
when: never
- if: '$CI_COMMIT_BRANCH =~ /^feature.*$/'
variables:
TARGET: dev
- if: "$CI_COMMIT_BRANCH"
我认为您可能混淆了可用和不可用的内容(而且我认为您链接的答案也是如此)。您完全可以使用变量来填充 运行 您的工作应该 运行 的内容,我今天在 SaaS 产品的工作流程中使用它。
使用变量来确定 运行ner 标记仍然会造成混淆,因为变量是否正常工作在很大程度上取决于您定义它的位置。如果您的变量在 CI/CD 管道的 root scope 内(即,在顶级 variable
块内或 workflow
块内) 它将正常工作。如果您试图在作业范围内定义规则(即在 job:rules:if:variables
块内),它 将无法正常工作 。由于您上面的示例在工作流块内,因此它将正确地 select 您的标签并将其应用于下游作业。
您可以在此处查看更多信息:https://gitlab.com/gitlab-org/gitlab/-/issues/35742#note_704836498
下面是一个证明动态标签的例子:
workflow:
rules:
- variables:
RUNNER: shared-macos-amd64
test:
image: alpine:latest
tags:
- $RUNNER
script:
- echo $CI_RUNNER_DESCRIPTION
这在 macOS 运行ner 上可以正常使用(并打印错误,因为我不在他们的测试版中):
更新@Patrick 的回答,我成功了,想描述一下我的解决方案。我的问题是由使用的变量引起的——当我使用 PR 进行测试时,我从未设置过 CI_COMMIT_BRANCH
,但使用 CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
它有效。
workflow:
rules:
# No build duplicates when committing to a branch with open pull request (PR)
- if: "$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS"
when: never
# Deploy to development when PR from feature-branch
- if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature.*$/"
variables:
TARGET: dev
# Deploy to test when committing (after merging) to develop-branch
- if: '$CI_COMMIT_BRANCH == "dev"'
variables:
TARGET: test
# Deploy to staging when committing (after merging) to release-branch
- if: '$CI_COMMIT_BRANCH =~ /^release\/.*$/'
variables:
TARGET: stage
# Deploy to production when committing (after merging) to master-branch
- if: '$CI_COMMIT_BRANCH == "main"'
variables:
TARGET: prod
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_PIPELINE_SOURCE == "parent_pipeline"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: "$CI_COMMIT_BRANCH"
解决办法在于使用predefined variables。
- CI_COMMIT_REF_NAME - 构建项目的分支或标签名称。
- CI_COMMIT_BRANCH - 提交分支名称。在分支管道中可用,包括默认分支的管道。在合并请求管道或标记管道中不可用。
- CI_BUILD_REF_NAME - 不清楚
- CI_MERGE_REQUEST_SOURCE_BRANCH_NAME - 合并请求的源分支名称。
- CI_MERGE_REQUEST_TARGET_BRANCH_NAME - 合并请求的目标分支名称。
- CI_OPEN_MERGE_REQUESTS - 最多四个使用当前分支和项目作为合并请求源的合并请求的逗号分隔列表。如果分支具有关联的合并请求,则仅在分支和合并请求管道中可用。比如gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11.
我找到了 following proposal 并对其进行了测试(参见代码示例),但无法使其正常工作。
我们运行在Gitlab 14.3.4上,我如何确定这个版本是否可用?如果此功能不起作用,如果我有不同的 运行ners,一个用于我的产品,一个用于开发环境,我该如何部署到不同的环境?到目前为止,我为每个使用其专用标签的环境都有一个管道——因为动态标签是
如有任何帮助,我们将不胜感激 - 谢谢!
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_PIPELINE_SOURCE == "parent_pipeline"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: "$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS"
when: never
- if: '$CI_COMMIT_BRANCH =~ /^feature.*$/'
variables:
TARGET: dev
- if: "$CI_COMMIT_BRANCH"
我认为您可能混淆了可用和不可用的内容(而且我认为您链接的答案也是如此)。您完全可以使用变量来填充 运行 您的工作应该 运行 的内容,我今天在 SaaS 产品的工作流程中使用它。
使用变量来确定 运行ner 标记仍然会造成混淆,因为变量是否正常工作在很大程度上取决于您定义它的位置。如果您的变量在 CI/CD 管道的 root scope 内(即,在顶级 variable
块内或 workflow
块内) 它将正常工作。如果您试图在作业范围内定义规则(即在 job:rules:if:variables
块内),它 将无法正常工作 。由于您上面的示例在工作流块内,因此它将正确地 select 您的标签并将其应用于下游作业。
您可以在此处查看更多信息:https://gitlab.com/gitlab-org/gitlab/-/issues/35742#note_704836498
下面是一个证明动态标签的例子:
workflow:
rules:
- variables:
RUNNER: shared-macos-amd64
test:
image: alpine:latest
tags:
- $RUNNER
script:
- echo $CI_RUNNER_DESCRIPTION
这在 macOS 运行ner 上可以正常使用(并打印错误,因为我不在他们的测试版中):
更新@Patrick 的回答,我成功了,想描述一下我的解决方案。我的问题是由使用的变量引起的——当我使用 PR 进行测试时,我从未设置过 CI_COMMIT_BRANCH
,但使用 CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
它有效。
workflow:
rules:
# No build duplicates when committing to a branch with open pull request (PR)
- if: "$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS"
when: never
# Deploy to development when PR from feature-branch
- if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature.*$/"
variables:
TARGET: dev
# Deploy to test when committing (after merging) to develop-branch
- if: '$CI_COMMIT_BRANCH == "dev"'
variables:
TARGET: test
# Deploy to staging when committing (after merging) to release-branch
- if: '$CI_COMMIT_BRANCH =~ /^release\/.*$/'
variables:
TARGET: stage
# Deploy to production when committing (after merging) to master-branch
- if: '$CI_COMMIT_BRANCH == "main"'
variables:
TARGET: prod
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_PIPELINE_SOURCE == "parent_pipeline"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: "$CI_COMMIT_BRANCH"
解决办法在于使用predefined variables。
- CI_COMMIT_REF_NAME - 构建项目的分支或标签名称。
- CI_COMMIT_BRANCH - 提交分支名称。在分支管道中可用,包括默认分支的管道。在合并请求管道或标记管道中不可用。
- CI_BUILD_REF_NAME - 不清楚
- CI_MERGE_REQUEST_SOURCE_BRANCH_NAME - 合并请求的源分支名称。
- CI_MERGE_REQUEST_TARGET_BRANCH_NAME - 合并请求的目标分支名称。
- CI_OPEN_MERGE_REQUESTS - 最多四个使用当前分支和项目作为合并请求源的合并请求的逗号分隔列表。如果分支具有关联的合并请求,则仅在分支和合并请求管道中可用。比如gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11.