Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
gitlab-foss
提交
a0fefc2a
G
gitlab-foss
项目概览
李少辉-开发者
/
gitlab-foss
通知
15
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
gitlab-foss
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
a0fefc2a
编写于
6月 14, 2016
作者:
M
Mark Pundsack
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Add definitions and tweak some docs. Partially fixes #17733
上级
032e3983
变更
4
隐藏空白更改
内联
并排
Showing
4 changed file
with
67 addition
and
14 deletion
+67
-14
doc/ci/README.md
doc/ci/README.md
+1
-0
doc/ci/definitions/README.md
doc/ci/definitions/README.md
+52
-0
doc/ci/quick_start/README.md
doc/ci/quick_start/README.md
+12
-12
doc/ci/yaml/README.md
doc/ci/yaml/README.md
+2
-2
未找到文件。
doc/ci/README.md
浏览文件 @
a0fefc2a
...
...
@@ -3,6 +3,7 @@
### CI User documentation
-
[
Get started with GitLab CI
](
quick_start/README.md
)
-
[
CI/CD Definitions
](
definitions/README.md
)
-
[
CI examples for various languages
](
examples/README.md
)
-
[
Learn how to enable or disable GitLab CI
](
enable_or_disable_ci.md
)
-
[
Environments and deployments
](
environments.md
)
...
...
doc/ci/definitions/README.md
0 → 100644
浏览文件 @
a0fefc2a
## CI/CD Definitions
### Pipelines
A pipeline is a group of [builds] that get executed in [stages] (batches). All of
the builds in a stage are executed in parallel (if there are enough concurrent
[runners]), and if they all succeed, the pipeline moves on to the next stage. If
one of the builds fails, the next stage is not (usually) executed.
### Builds
Builds are runs of [jobs]. Not to be confused with a
`build`
stage.
### Jobs
Jobs are the basic work unit of CI/CD. Jobs are used to create [builds], which are
then picked up by [Runners] and executed within the environment of the Runner.
Each job is run independently from each other.
### Runners
A runner is an isolated (virtual) machine that picks up builds through the
coordinator API of GitLab CI. A runner can be specific to a certain project or
serve any project in GitLab CI. A runner that serves all projects is called a
shared runner.
### Stages
Stages allow [jobs] to be grouped into parallel and sequential [builds]. Builds
of the same stage are executed in parallel and builds of the next stage are run
after the jobs from the previous stage complete successfully. Stages allow for
flexible multi-stage [pipelines]. By default [pipelines] have
`build`
,
`test`
and
`deploy`
stages, but these can be defined in
`.gitlab-ci.yml`
. If a job
doesn't specify a stage, the job is assigned to the test stage.
### Environments
Environments are places where code gets deployed, such as staging or production.
CI/CD [Pipelines] usually have one or more deploy stages with [jobs] that do
[deployments] to an environment.
### Deployments
Deployments are created when [jobs] deploy versions of code to [environments].
[
pipelines
]:
#pipelines
[
builds
]:
#builds
[
runners
]:
#runners
[
jobs
]:
#jobs
[
stages
]:
#stages
[
environments
]:
#environments
[
deployments
]:
#deployments
doc/ci/quick_start/README.md
浏览文件 @
a0fefc2a
...
...
@@ -4,41 +4,40 @@
is fully integrated into GitLab itself and is [enabled] by default on all
projects.
The TL;DR version of how GitLab CI works is the following.
---
GitLab offers a
[
continuous integration
][
ci
]
service. If you
[
add a `.gitlab-ci.yml` file
][
yaml
]
to the root directory of your repository,
and configure your GitLab project to use a [Runner], then each merge request or
push triggers
a build
.
push triggers
your CI [pipeline]
.
The
`.gitlab-ci.yml`
file tells the GitLab runner what to do. By default it
runs three [stages]:
`build`
,
`test`
, and
`deploy`
.
runs
a pipeline with
three [stages]:
`build`
,
`test`
, and
`deploy`
.
If everything runs OK (no non-zero return values), you'll get a nice green
checkmark associated with the pushed commit or merge request. This makes it
easy to see whether a merge request
will cause
any of the tests to fail before
easy to see whether a merge request
caused
any of the tests to fail before
you even look at the code.
Most projects
only
use GitLab's CI service to run the test suite so that
Most projects use GitLab's CI service to run the test suite so that
developers get immediate feedback if they broke something.
There's a growing trend to use continuous delivery and continuous deployment to
automatically deploy tested code to staging and production environments.
So in brief, the steps needed to have a working CI can be summed up to:
1.
Add
`.gitlab-ci.yml`
to the root directory of your repository
1.
Configure a Runner
From there on, on every push to your Git repository, the
build will be
automagically start
ed by the Runner and will appear under the project's
`/build
s`
page.
From there on, on every push to your Git repository, the
Runner will
automagically start
the pipeline and the pipeline will appear under the
project's
`/pipeline
s`
page.
---
This guide assumes that you:
-
have a working GitLab instance of version 8.0 or higher or are using
[
GitLab.com
](
https://gitlab.com
/users/sign_in
)
[
GitLab.com
](
https://gitlab.com
)
-
have a project in GitLab that you would like to use CI for
Let's break it down to pieces and work on solving the GitLab CI puzzle.
...
...
@@ -238,3 +237,4 @@ CI with various languages.
[
runner
]:
../runners/README.md
[
enabled
]:
../enable_or_disable_ci.md
[
stages
]:
../yaml/README.md#stages
[
pipeline
]:
../definitions/README.md#pipelines
doc/ci/yaml/README.md
浏览文件 @
a0fefc2a
...
...
@@ -54,7 +54,7 @@ of your repository and contains definitions of how your project should be built.
The YAML file defines a set of jobs with constraints stating when they should
be run. The jobs are defined as top-level elements with a name and always have
to contain the
`script`
clause:
to contain
at least
the
`script`
clause:
```
yaml
job1
:
...
...
@@ -165,7 +165,7 @@ stages:
There are also two edge cases worth mentioning:
1.
If no
`stages`
is
defined in
`.gitlab-ci.yml`
, then by default the
`build`
,
1.
If no
`stages`
are
defined in
`.gitlab-ci.yml`
, then by default the
`build`
,
`test`
and
`deploy`
are allowed to be used as job's stage by default.
2.
If a job doesn't specify a
`stage`
, the job is assigned the
`test`
stage.
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录