我目前在 GitLab 和 Heroku 中有我的项目。我想做的是,当我向我的特性分支发出合并请求时(我们称之为crud-on-spaghetti
),我想自动在这个分支上运行测试(基本上是npm test
,用摩卡/柴),等他们成功后,把这个crud-on-spaghetti
和master
合并,提交并推送到origin/master
(在GitLab上是远程的)以及git push heroku master
之后(基本上是把它推到Heroku的master分支,我的应用程序就存储在那里)我读过几篇关于GitLab CI的文章,我认为这更适合我(而不是Heroku CI,因为我没有DEV和PROD示例)。
所以,到目前为止,我是手动完成的。这是我现在的.gitlab-ci.yml
文件(还没有提交/推送):
stages:
- test
- deploy
test_for_illegal_bugs:
stage: test
script:
- npm test
deploy_to_dev:
stage: deploy
only:
- origin master
script:
- git commit
- git push origin master
- git pull heroku master --rebase
- git push heroku master
因此,我的问题是:为了自动化所有这些“操作”(如上所述),我到底需要在.gitlab-ci.yml
中编写什么?
附言:还有一个(理论上的)后续问题:GitLab-CI Runner是如何被触发的?例如,如果我想让它在与master的合并请求时触发,我是否可以在.gitlab-ci.yml
中使用only: ...
来实现?
3条答案
按热度按时间fhity93d1#
限制合并请求的阶段:
要使
test
stage仅在打开合并请求(MR)时执行,请使用根据Gitlab文档,您可以进一步将此限制为仅对具有特定目标分支的MR执行,例如仅对
master
的MR执行这会为所有不是
master
的目标分支添加一个异常。或者使用
rules:
:将阶段限制为分支:
正如@marcolz已经提到的,这是通过以下方式实现的
以仅执行用于推送到主分支的阶段。
m528fe3b2#
试试看
origin
只是远程的名称。master
是分支的名称。这个runner由GitLab-CI在一个提交被推送到仓库的时候触发,所以不是在合并请求的时候。
可以使用
trigger
触发管道,然后从integrations
中的合并请求事件调用该触发器。dfuffjeb3#
我不确定,但我认为应该使用的规则是检测"结果合并事件":
参见https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipelines.html
否则,不管合并请求是否被批准以及是否成功完成,阶段都可能运行。