构建后的测试将在gitlab-ci上的新环境中运行
我具有以下配置,如.gitlab-ci.yml 但我成功通过了构建阶段后发现 会创建一个称为venv的virtualenv),似乎 在测试阶段,您将获得一个全新的环境( 根本没有venv目录).所以我想知道我应该设置 为此,它将在每个阶段(构建/测试/部署)中运行.这是正确的方法吗?
I have the following configuration as .gitlab-ci.yml but I found out after successfully pass build stage (which would create a virtualenv called venv), it seems that in test stage you would get a brand new environment(there's no venv directory at all). So I wonder should I put setup script in before_script therefor it would run in each phase(build/test/deploy). Is it a right way to do it ?
before_script:
- uname -r
types:
- build
- test
- deploy
job_install:
type: build
script:
- apt-get update
- apt-get install -y libncurses5-dev
- apt-get install -y libxml2-dev libxslt1-dev
- apt-get install -y python-dev libffi-dev libssl-dev
- apt-get install -y python-virtualenv
- apt-get install -y python-pip
- virtualenv --no-site-packages venv
- source venv/bin/activate
- pip install -q -r requirements.txt
- ls -al
only:
- master
job_test:
type: test
script:
- ls -al
- source venv/bin/activate
- cp crawler/settings.sample.py crawler/settings.py
- cd crawler
- py.test -s -v
only:
- master
戒备
Gitlab CI作业应该是独立的,因为它们可以在不同的运行程序上运行.这不是问题.在阶段之间传递文件有两种方法:
Gitlab CI jobs supposed to be independent, because they could run on different runners. It is not issue. There two ways to pass files between stages:
- 正确的方法.使用人工制品.
- 错误的方式.使用缓存.带有缓存键"hack".仍然需要同一个跑步者.
是的,以gitlab的方式应该可以让您的工作依赖于脚本之前的所有内容.
So yes, supposed by gitlab way to have everything your job depends on in before script.
工件示例:
artifacts:
when: on_success
expire_in: 1 mos
paths:
- some_project_files/
缓存示例:
cache:
key: "$CI_BUILD_REF_NAME"
untracked: true
paths:
- node_modules/
- src/bower_components/
对于正确的运行环境,我建议将docker与包含apt-get依赖项的映像一起使用.并使用人工制品在作业之间传递作业结果.请注意,artefact也已上传到gitlab Web界面,并能够下载它们.因此,如果它们很繁重,请使用较小的expire_in时间,以便在完成所有作业后将其删除.
For correct running environment i suggest using docker with image containing apt-get dependencies. And use artefacts for passing job results between jobs. Note that artefact also uploaded to gitlab web interface and being able to download them. So if they are quite heavy use small expire_in time, for removing them after all jobs done.