gitLab基础

star

image.png

在gitLab项目的主页中，我们可以看到star，fork，clone三个按钮，star是为了帮助我们在日常的工作中更加快捷的找到我们的项目，因为可能在工作中有很多个项目，怎样可以快速的找到我们关注的项目，此时就可以给这个项目加个star，然后.....

image.png

就可以看到它们了
web IDE

image.png

这个界面打开时是这个样子的：

image.png

是不是发现了新大陆
snippets
定义一些代码片段，每个人都可以将自己写的代码片段给大家分享出去。
wiki
书写一些项目的介绍和引导的内容，相当于一个记录
issue
列出一些问题，以后可以去解决。或者是可以优化，为了防止自己遗忘它们
group和subgroup
组和子组
namespace
指的是我们在创建一个项目都常时候，会自动将项目归于个人（username）组（group）子组（subgroup）防止项目的命名冲突。

gitLab的角色说明

Role permissions
Guest 无代码，提 issue，下载 artifacts，看 wiki 等周边性工作
Reporter 可下载代码，看 MR，等所有开发可见的东西
Developer 普通开发者，可以提 MR，给代码提意见，触发 CI 等
Maintainer 对整个项目配置进行修改，修改 branch protection，runner，ci variable 等
Owner 可以删库

merge request

image.png

进入merge request的页面

image.png

然后在compare之后，你就可以看到两个分支上不同的提交信息，你还可以为你本次的merge请求书写标题，详细的说明，以及将它assign给其他人让他们帮你review.....

image.png

WIP（Work In Progress）
以WIP开头的merge request是不会被自动merge的，除非你手动删除WIP的标识，或者手动触发merge行为。

image.png

gitLab的CI/CD

Continuous Integration (CI) - 持续集成
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
Continuous Delivery (CD) - 持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
Continuous Deployment (CD) - 持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

runner，一个执行软件集成脚本的东西

gitLab的ci：
一个最简单的ci:
.gitlab-ci.yml 该文件需要在项目的根目录下

stages:
  - test
test:
  image: alpine:latest
  tags: 
    - docker-runner
  stage: test
  script:
    - echo 'hello word!'
  only:
    - master

注意
stages是串行的
jobs是并行的

上面的ci的job名称就是
test
job name：
xxxx
stage: stage name

image.png

下面的这些字段不能定义为job名

关键字	是否必须	描述
image	否	用于docker镜像，查看docker文档
services	否	用于docker服务，查看docker文档
stages	否	定义构建阶段
types	否	`stages` 的别名(已废除)
before_script	否	定义在每个job之前运行的命令
after_script	否	定义在每个job之后运行的命令
variable	否	定义构建变量
cache	否	定义一组文件列表，可在后续运行中使用

每一个job下可以使用的配置

image-要使用的镜像

常用的镜像

nodejs
alpine
busybox
debian

before_script

用来定义所有job之前运行的命令，包括deploy(部署) jobs，但是在修复artifacts之后。它可以是一个数组或者是多行字符串。

after_script

用来定义所有job之后运行的命令。它必须是一个数组或者是多行字符串

stage

定义当前job所属的stage

stages

stages的规范允许有灵活的多级pipelines,每一个stages就是一级pipelines
可以在stages下定义多个stage

stages:
  - build
  - test
  - deploy

首先，所有build的jobs都是并行执行的。
所有build的jobs执行成功后，test的jobs才会开始并行执行。
所有test的jobs执行成功，deploy的jobs才会开始并行执行。
所有的deploy的jobs执行成功，commit才会标记为success
任何一个前置的jobs失败了，commit会标记为failed并且下一个stages的jobs都不会执行。

注意

如果.gitlab-ci.yml中没有定义stages，那么job's stages 会默认定义为 build，test 和 deploy。
如果一个job没有指定stage，那么这个任务会分配到test stage。

variables

GItLab CI 允许在.gitlab-ci.yml文件中添加变量，并在job环境中起作用。因为这些配置是存储在git仓库中，所以最好是存储项目的非敏感配置，可以在.gitlab-ci.yml文件中定义，也可以在gitlab的极界面上定义

variables: &deploy_variables
    GIT_STRATEGY: none

还有一些runner中的变量：
eg:

$CI_JOB_NAME 当前运行的job名称
$CI_COMMIT_REF_SLUG
$CI_COMMIT_REF_NAME 当前所在的分支

cache

用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径

如果cache定义在jobs的作用域之外，那么它就是全局缓存，所有jobs都可以使用该缓存。

stages:
  - test
  - build
  - deploy

test:
  image: alpine:latest
  tags: 
    - docker-runner
  cache: #在某一个job下定义cache，缓存node_modules下的所有文件
    untracked: true #缓存node_modules中git没有跟踪的文件
    key: $CI_JOB_NAME--$CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
  stage: test
  script:
    - echo 'hello word!'
  only:
    - master

注意，缓存是在jobs之前进行共享的。如果你不同的jobs缓存不同的文件路径，必须设置不同的cache:key，否则缓存内容将被重写

缓存key

key指令允许我们定义缓存的作用域(亲和性)，可以是所有jobs的单个缓存，也可以是每个job，也可以是每个分支或者是任何你认为合适的地方。

配置示例

缓存每个job：

cache:
key: "$CI_JOB_NAME"
untracked: true
缓存每个分支：

cache:
key: "$CI_COMMIT_REF_NAME"
untracked: true
缓存每个job且每个分支：

cache:
key: "CI_COMMIT_REF_NAME"
untracked: true
缓存每个分支且每个stage：

cache:
key: "CI_COMMIT_REF_NAME"
untracked: true

jobs

允许指定无限量jobs。每个jobs必须有一个唯一的名字，而且不能是上面提到的关键字。job由一列参数来定义jobs的行为。
jobs参数

Keyword	Required	Description
script	yes	Runner执行的命令或脚本
image	no	所使用的docker镜像，查阅使用docker镜像
services	no	所使用的docker服务，查阅使用docker镜像
stage	no	定义job stage（默认：`test`）
type	no	`stage`的别名（已弃用）
variables	no	定义job级别的变量
only	no	定义一列git分支，并为其创建job
except	no	定义一列git分支，不创建job
tags	no	定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags）
allow_failure	no	允许job失败。失败的job不影响commit状态
when	no	定义何时开始job。可以是`on_success`，`on_failure`，`always`或者`manual`
dependencies	no	定义job依赖关系，这样他们就可以互相传递artifacts
cache	no	定义应在后续运行之间缓存的文件列表
before_script	no	重写一组在作业前执行的命令
after_script	no	重写一组在作业后执行的命令
environment	no	定义此作业完成部署的环境名称
coverage	no	定义给定作业的代码覆盖率设置

only和except可同时使用。如果only和except在一个job配置中同时存在，则以only为准，跳过except(从下面示例中得出)。

job:
  only:
    - branches@gitlab-org/gitlab-ce #@后面是你额仓库名称地址，也就是$CI_PROJECT_PATH的值
  except:
    - master@gitlab-org/gitlab-ce

when

when可以设置以下值：

on_success - 只有前面stages的所有工作成功时才执行。这是默认值。
on_failure - 当前面stages中任意一个jobs失败后执行。
always - 无论前面stages中jobs状态如何都执行。
manual - 手动执行(GitLab8.10增加)

environment

environment:
    name: production
    url: http://xxx.com

dynamic environment

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

job将会被指定部署到动态创建review/CI_ENVIRONMENT_SLUG变量是基于环境名称的，最终组合成完整的URLs。在这种情况下，如果deploy as review app job是运行在名称为pow的分支下，那么可以通过URL https"//review-pw.example.com/来访问这个环境.

artifacts

artifacts用于指定成功后应附加到job的文件和目录的列表。只能使用项目工作间内的文件或目录路径。

发送binaries和.config中的所有文件：

artifacts:
  paths:
  - binaries/
  - .config

发送所有没有被Git跟踪的文件：

artifacts:
  untracked: true

发送没有被Git跟踪和binaries中的所有文件：

artifacts:
  untracked: true
  paths:
  - binaries/

定义一个空的dependencies可以禁用artifact传递：

job:
  stage: build
  script: make build
  dependencies: []

有时候只需要为标签为releases创建artifacts，以避免将临时构建的artifacts传递到生产服务器中。
在job成功完成后artifacts将会发送到GitLab中，同时也会在GitLab UI中提供下载。

image.png

artifacts:name

name允许定义创建的artifacts存档的名称。这样一来，我们可以为每个存档提供一个唯一的名称，当需要从GitLab中下载是才不会混乱。artifacts:name可以使用任何的预定义变量(predefined variables)。它的默认名称为artifacts，当下载是就变成了artifacts.zip。

配置示例

通过使用当前job的名字作为存档名称：

job:
  artifacts:
    name: "$CI_JOB_NAME"

使用当前分支名称或者是tag作为存到名称，只存档没有被Git跟踪的文件：

job:
   artifacts:
     name: "$CI_COMMIT_REF_NAME"
     untracked: true

使用当前job名称和当前分支名称或者是tag作为存档名称，只存档没有被Git跟踪的文件：

job:
  artifacts:
    name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
    untracked: true

使用当前stage和分支名称作为存档名称：

job:
  artifacts:
    name: "${CI_JOB_STAGE}_${CI_COMMIT_REF_NAME}"
    untracked: true

artifacts:when

artifacts:when可以设置一下值：

on_success - 当job成功的时候上传artifacts。默认值。
on_failure - 当job失败的时候上传artifacts。
always - 不论job失败还是成功都上传artifacts。

示例配置

只在job失败的时候上传artifacts。

job:
  artifacts:
    when: on_failure

artifacts:expire_in

artifacts:expire_in用于过期后删除邮件上传的artifacts。默认情况下，artifacts都是在GitLab中永久保存。expire_in允许设置设置artifacts的存储时间，从它们被上传存储到GitLab开始计算。

可以通过job页面的Keep来修改有效期。

过期后，artifacts会被通过一个默认每小时执行一次的定时job删除，所以在过期后无法访问artifacts。

expire_in是一个时间区间。下面可设置的值：

'3 mins 4 sec'
'2 hrs 20 min'
'2h20min'
'6 mos 1 day'
'47 yrs 6 mos and 4d'
'3 weeks and 2 days'

示例配置

设置artifacts的有效期为一个星期：

job:
  artifacts:
    expire_in: 1 week

dependencies

dependencies:
    - build:review

列出当前job所依赖的job。被依赖的job需要在前面已经定义

Git Strategy

你可以通过设置GIT_STRATEGY用于获取最新的代码，可以再全局variables或者是在单个job的variables模块中设置。如果没有设置，将从项目中使用默认值。

可以设置的值有：clone，fetch，和none
clone是最慢的选项。它会从头开始克隆整个仓库，包含每一个job，以确保项目工作区是最原始的。

variables:
  GIT_STRATEGY: clone

当它重新使用项目工作区是，fetch是更快（如果不存在则返回克隆）。git clean用于撤销上一个job做的任何改变，git fetch用于获取上一个job到现在的commit。

variables:
  GIT_STRATEGY: fetch

none也是重新使用项目工作区，但是它会跳过所有的Git操作（包括GitLab Runner前的克隆脚本，如果存在的话）。它主要用在操作job的artifacts（例如：deploy）。Git数据仓库肯定是存在的，但是他肯定不是最新的，所以你只能依赖于从项目工作区的缓存或者是artifacts带来的文件。

variables:
  GIT_STRATEGY: none

Job stages attempts

正在执行的job将会按照你设置尝试次数依次执行下面的stages：

变量描述
GET_SOURCES_ATTEMPTS 获取job源的尝试次数
ARTIFACT_DOWNLOAD_ATTEMPTS 下载artifacts的尝试次数
RESTORE_CACHE_ATTEMPTS 重建缓存的尝试次数
默认是一次尝试。

例如：

variables:
  GET_SOURCES_ATTEMPTS: 3

你可以在全局variables模块中设置，也可以在单个job的variables模块中设置。

Hidden keys

Key 是以.开始的，GitLab CI 将不会处理它。你可以使用这个功能来忽略jobs，或者用Special YAML features 转换隐藏键为模版。
Hidden keys 可以是像普通CI jobs一样的哈希值，但你也可以利用special YAMLfeatures来使用不同类型的结构。

Special YAML features

使用special YAML features 像anchors(&)，aliases(*)和map merging(<<)，这将使您可以大大降低.gitlab-ci.yml的复杂性。

Anchors

YAML有个方便的功能称为"锚",它可以让你轻松的在文档中复制内容。Anchors可用于复制/继承属性，并且是使用hidden keys来提供模版的完美示例。
下面这个例子使用了anchors和map merging。它将会创建两个jobs，test1和test2，该jobs将集成.job_template的参数，每个job都自定义脚本：

.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test1 project

test2:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test2 project

&在anchor的名称(job_definition)前设置，<<表示"merge the given hash into the current one"，*包括命名的anchor(job_definition)。扩展版本如下：

.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test1 project

test2:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test2 project

让我们来看另外一个例子。这一次我们将用anchors来定义两个服务。两个服务会创建两个job，test:postgres和test:mysql，他们会在.job_template中共享定义的script指令，以及分别在.postgres_services和.mysql_services中定义的service指令：

.job_template: &job_definition
  script:
    - test project

.postgres_services:
  services: &postgres_definition
    - postgres
    - ruby

.mysql_services:
  services: &mysql_definition
    - mysql
    - ruby

test:postgres:
  <<: *job_definition
  services: *postgres_definition

test:mysql:
  <<: *job_definition
  services: *mysql_definition

等价于：

.job_template:
 script:
   - test project

.postgres_services:
 services:
   - postgres
   - ruby

.mysql_services:
 services:
   - mysql
   - ruby

test:postgres:
 script:
   - test project
 services:
   - postgres
   - ruby

test:mysql:
 script:
   - test project
 services:
   - mysql
   - ruby

Pages

pages是一个特殊的job，用于将静态的内容上传到GitLab，可用于为您的网站提供服务。它有特殊的语法，因此必须满足以下两个要求：

任何静态内容必须放在public/目录下
artifacts必须定义在public/目录下
下面的这个例子是将所有文件从项目根目录移动到public/目录。.public工作流是cp，并且它不会循环复制public/本身。

pages:
  stage: deploy
  script:
  - mkdir .public
  - cp -r * .public
  - mv .public public
  artifacts:
    paths:
    - public
  only:
  - master

gitLab的初识

gitLab基础

gitLab的角色说明

merge request

gitLab的CI/CD

image-要使用的镜像

before_script

after_script

stage

stages

variables

cache

缓存key

jobs

when

environment

dynamic environment

artifacts

artifacts:name

artifacts:when

artifacts:expire_in

dependencies

Git Strategy

Job stages attempts

Hidden keys

Special YAML features

Anchors

Pages

你可能感兴趣的:(gitLab的初识)