Show More
@@ -1,3 +1,20 b'' | |||
|
1 | # Don't run pipelines on branch "merge", since we're fast-forward only. | |
|
2 | # Gitlab sees a new branch (since e.g. `topic/stable/my-topic` becomes | |
|
3 | # `branch/stable`), but the hash hasn't changed. There is no reason to | |
|
4 | # re-run the CI in our case, since we haven't built up any specific automation. | |
|
5 | # Right now it's just wasted CI and developer time. | |
|
6 | # One can still run the pipeline manually via the web interface or a push, | |
|
7 | # like in the case of releases, to make *extra* sure that the actual branch | |
|
8 | # has succeeded. | |
|
9 | workflow: | |
|
10 | rules: | |
|
11 | - if: $CI_COMMIT_BRANCH =~ /^branch\// && $CI_PIPELINE_SOURCE != "web" && $CI_PIPELINE_SOURCE != "push" | |
|
12 | when: never | |
|
13 | - if: $CI_PIPELINE_SOURCE == "merge_request_event" | |
|
14 | - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS | |
|
15 | when: never | |
|
16 | - if: $CI_COMMIT_BRANCH | |
|
17 | ||
|
1 | 18 | stages: |
|
2 | 19 | - tests |
|
3 | 20 |
General Comments 0
You need to be logged in to leave comments.
Login now