我是 GitLab CI 的新手，尝试设置一个在创建合并请求时需要触发的构建。目前，构建在 MR 被接受并合并到“开发”分支后运行。这很好。但我也期望在创建 MR 时构建能够运行。
我的 gitlab-ci.yml 如下 - 我错过了什么吗？
stages:
- test
test_project:
stage: test
script:
- xcodebuild -scheme CodeRedTests -sdk iphonesimulator10.2 -workspace CodeRed.xcworkspace -configuration Debug clean build test -destination "platform=iOS Simulator,OS=10.2,name=iPhone 5s" | xcpretty -s
only:
- develop
tags:
- ios_10
- xcode_8
- osx_10-12
最佳答案
创建 MR 时运行测试已 hot topic从2015年开始，甚至更久。 准确地说，需要在某个管道中对合并的代码(从您的分支到开发)运行测试。如果一切正常，那么 MR 就会亮绿灯。
目前尚不可用。一个doc说:
In old workflows the Continuous Integration (CI) server commonly ran tests on the master branch only. Developers had to ensure their code did not break the master branch. When using GitLab flow developers create their branches from this master branch so it is essential it is green. Therefore each merge request must be tested before it is accepted. CI software like Travis and GitLab CI show the build results right in the merge request itself to make this easy. One drawback is that they are testing the feature branch itself and not the merged result. What one can do to improve this is to test the merged result itself. The problem is that the merge result changes every time something is merged into master. Retesting on every commit to master is computationally expensive and means you are more frequently waiting for test results. If there are no merge conflicts and the feature branches are short lived the risk is acceptable. If there are merge conflicts you merge the master branch into the feature branch and the CI server will rerun the tests. If you have long lived feature branches that last for more than a few days you should make your issues smaller.
因此，您可以尝试将开发合并到功能分支以确保一切正常，但您必须删除 only:develop 限制。
关于gitlab - 如何在 MR 上运行 GitLab CI 构建？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41674762/