英文:
Pushing new branch GitLab
问题
我有一个类似这样的GitlabCI配置。
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- changes:
- .gitlab-ci.yml
when: never
- if: $CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/
这个工作是针对像release/x.y.z这样的分支的。
问题在于，当我第一次推送分支时，CI不会触发。根据我从GitLab日志中看到的信息，它将分支的最后一次提交与空提交（0000000000000000000000000000000000000000）进行比较，因此不会触发。但如果第一次推送分支时触发CI会很好。在这种情况下，最佳做法是什么？
我期望在第一次推送分支时触发CI。
英文:
I have GitlabCI like this.
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- changes:
- .gitlab-ci.yml
when: never
- if: $CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/
This job is for branches like release/x.y.z
The thing is that the CI is not triggered when I push the branch for the first time. As I saw from the GitLab logs it compares the last commit of the branch with the null commit (0000000000000000000000000000000000000000) and therefore it is not triggered. But it would be nice if it was triggered for first time the branch is pushed. What is the best practice in this situation?
I expect the CI to be triggered when I push the branch for the first time.
答案1
得分: 1
尝试在你的规则中添加 when: always：
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- changes:
- .gitlab-ci.yml
when: never
- if: '$CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/'
when: always
> 实际上，当它将最后一次提交与空提交进行比较时，CI文件是新的，条件 "changes" 生效，它将 不 查找第二个条件。
第一条规则中的 changes 子句可能确实导致了问题。当你推送一个新分支时，.gitlab-ci.yml 文件在该分支的上下文中被视为新文件，并且具有 when: never 的第一条规则将优先执行。
所以：
- 我们将显式包含对空提交SHA的检查，以确保这条规则在第一次推送时不会阻止CI。
- 我们将使用一个单一规则来处理分支模式，不涉及
changes子句。
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- if: '$CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/' || ($CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000" && $CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/)
when: always
这个配置使用一个单一规则，确保流水线触发与匹配 release/x.y.z 模式的分支相关。同时，它包括对空提交SHA的显式检查，与分支模式检查结合使用。这应该适用于两种情况：新分支的第一次推送和随后的推送。
英文:
Try adding when: always to your rule:
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- changes:
- .gitlab-ci.yml
when: never
- if: '$CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/'
when: always
> Actually, when it compares the last commit with the null one, the CI file is new, and the "changes" condition takes place, it will not look for the second condition.
The changes clause in the first rule might be causing the issue indeed. When you push a new branch, the .gitlab-ci.yml file is considered new in the context of that branch, and the first rule with when: never is taking precedence.
So:
- We will explicitly include the check for the null commit SHA to make sure this rule does not block the CI when it is the first push.
- We will use a single rule for the branch pattern without involving the
changesclause.
STAGE:
stage: deploy
image:
name: bitnami/kubectl:1.26
entrypoint: [""]
script:
...
rules:
- if: '$CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/ || ($CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000" && $CI_COMMIT_REF_NAME =~ /^release\/\d+\.\d+\.\d+$/)'
when: always
This configuration uses a single rule to ensure that the pipeline is triggered for branches that match the release/x.y.z pattern.
It also includes an explicit check for the null commit SHA, combined with the branch pattern check.
This should cater to both scenarios: the first push of a new branch and subsequent pushes.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论