我是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
答案 0 :(得分：5)
自2015年以来，创建MR时运行测试的时间为hot topic，甚至更长。 准确地说，需要在某些管道中对合并代码（从您的分支开发）运行测试。如果一切都好，那么MR就会开绿灯。
目前它还没有尚未。 doc说：
在旧工作流程中，持续集成（CI）服务器通常运行 仅在主分支上进行测试。开发人员必须确保他们的代码 没有打破主分支。使用GitLab流程开发人员时 从这个主分支创建它们的分支，所以它是必不可少的 绿色。因此，必须先测试每个合并请求 公认。像Travis和GitLab CI这样的CI软件显示了构建结果 在合并请求本身，以使这很容易。一个缺点是 他们正在测试功能分支本身而不是合并 结果。可以做些什么来改善这一点是测试合并的结果 本身。问题是合并结果每次都会改变 有些东西被合并为主人。每次提交都要重新测试 计算成本高，意味着你更频繁地等待 测试结果。 如果没有合并冲突和功能 分支是短暂的，风险是可以接受的。如果有合并 您将主分支合并到功能分支和 CI服务器将重新运行测试。如果您有长期使用的功能 分支持续超过几天你应该做你的 问题较小。
因此，您可以尝试将开发合并到您的功能分支以确保一切正常，但您必须删除only: develop限制。