摘要:什么是持續集成持續集成,簡稱指的是,頻繁地一天多次將代碼集成到主干。如圖什么是一次其實相當于一次構建任務,里面可以包含多個流程,如安裝依賴運行測試編譯部署測試服務器部署生產服務器等流程。參考鏈接用進行持續集成
什么是持續集成 ?
持續集成(Continuous integration,簡稱CI)指的是,頻繁地(一天多次)將代碼集成到主干。
GitLab CI 什么是 GitLab CI ?GitLab CI 是 GitLab Continuous Integration (Gitlab 持續集成)的簡稱。從 GitLab 的 8.0 版本開始,GitLab 就全面集成了 Gitlab-CI,并且對所有項目默認開啟。只要在項目倉庫的根目錄添加 .gitlab-ci.yml 文件,并且配置了 Runner (運行器),那么每一次合并請求(MR)或者 push 都會觸發 CI pipeline。
如果一切運行正常,你將得到與 commit 關聯的標記。如圖:
什么是 Pipeline ?一次 Pipeline 其實相當于一次構建任務,里面可以包含多個流程,如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。
任何提交或者 Merge Request 的合并都可以觸發 Pipeline,如下圖所示:
+------------------+ +----------------+ | | trigger | | | Commit / MR +---------->+ Pipeline | | | | | +------------------+ +----------------+什么是 Stages ?
Stages 表示構建階段,說白了就是上面提到的流程。
我們可以在一次 Pipeline 中定義多個 Stages,這些 Stages 會有以下特點:
所有 Stages 會按照順序運行,即當一個 Stage 完成后,下一個 Stage 才會開始
只有當所有 Stages 完成后,該構建任務 (Pipeline) 才會成功
如果任何一個 Stage 失敗,那么后面的 Stages 不會執行,該構建任務 (Pipeline) 失敗
因此,Stages 和 Pipeline 的關系就是:
+--------------------------------------------------------+ | | | Pipeline | | | | +-----------+ +------------+ +------------+ | | | Stage 1 |---->| Stage 2 |----->| Stage 3 | | | +-----------+ +------------+ +------------+ | | | +--------------------------------------------------------+什么是 Jobs ?
Jobs 表示構建工作,表示某個 Stage 里面執行的工作。
我們可以在 Stages 里面定義多個 Jobs,這些 Jobs 會有以下特點:
相同 Stage 中的 Jobs 會并行執行
相同 Stage 中的 Jobs 都執行成功時,該 Stage 才會成功
如果任何一個 Job 失敗,那么該 Stage 失敗,即該構建任務 (Pipeline) 失敗
所以,Jobs 和 Stage 的關系圖就是:
+------------------------------------------+ | | | Stage 1 | | | | +---------+ +---------+ +---------+ | | | Job 1 | | Job 2 | | Job 3 | | | +---------+ +---------+ +---------+ | | | +------------------------------------------+安裝配置
安裝環境為 Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-105-generic x86_64) ,docker 版本為 Docker version 18.03.1-ce, build 9ee9f40
安裝 gitlab-ci-multi-runner
# For Debian/Ubuntu curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash # For RHEL/CentOS curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
查看 docker images
sudo docker images如何使用 GitLab CI ?
在項目根目錄創建 .gitlab-ci.yml 文件,文件代碼如下:
stages 定義 Stages,默認有三個 Stages,分別是 build,test,deploy。Job.only 定義只有 develop 分支會觸發相關的 Jobs。
stages: - build job1: # 是否開啟 debug 模式 # variables: # CI_DEBUG_TRACE: "true" stage: build tags: - 新建 runner 的標簽 only: - develop script: - cd public - npm i - npm run build
進入 pipeline 配置頁面
記下 URL 和 Token,留以注冊 runner 使用
注冊 runner注冊 runner,runner 注冊成功之后,你會在 pipeline 配置頁面看見 specific runners 下多出了你剛新增的 runner。
sudo gitlab-ci-multi-runner register # Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ) 你的 URL # Please enter the gitlab-ci token for this runner 你的 Token # Please enter the gitlab-ci description for this runner my-runner # Please enter the gitlab-ci tags for this runner (comma separated) my-runner Whether to run untagged builds [true/false]: false Whether to lock Runner to current project [true/false]: false # Please enter the executor: shell, docker, docker-ssh, ssh? docker # Please enter the Docker image (eg. ruby:2.1): node:9.4.0
卸載 runner
sudo gitlab-ci-multi-runner unregister --url url地址 --token tocken值
查看 runner 狀態
sudo gitlab-ci-multi-runner status
查看 runner 列表
sudo gitlab-ci-multi-runner list
查看 runner 配置文件
sudo vim /etc/gitlab-runner/config.toml大功告成
切換到項目 Pipelines 頁面,發現出現以下情況,則代表你的 runner 已經配置完成,你的每一次提交都會觸發 runner。
備注使用 GitLab CI 克隆私有倉庫時候,會提示 Host key verification failed。
需要做如下配置,Key 寫入 SSH_PRIVATE_KEY,Value 寫入 服務器 private SSH key。然后在 .gitlab-ci.yml 文件前面寫入如下代碼,并保存。
before_script: - "which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )" # Run ssh-agent (inside the build environment) - eval $(ssh-agent -s) # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store - ssh-add <(echo "$SSH_PRIVATE_KEY") - mkdir -p ~/.ssh - "[[ -f /.dockerenv ]] && echo -e "Host * StrictHostKeyChecking no " > ~/.ssh/config"參考鏈接
Getting GitLab CI to clone private repositories
用 GitLab CI 進行持續集成
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/96077.html
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:來這里看看的工程師如何進行持續集成與持續部署。主要介紹了豆瓣移動持續集成和測試相關實踐,用工具化自動化社會化測試來解決遇到的問題,將打包發布環節自動化。這期的持續集成實踐分享就到這里。 我們常看到許多團隊和開發者分享他們的持續集成實踐經驗,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等項目搭建持續集成的實踐,以及一些國內外公司的內部持續集成...
閱讀 1229·2021-11-24 09:39
閱讀 379·2019-08-30 14:12
閱讀 2592·2019-08-30 13:10
閱讀 2434·2019-08-30 12:44
閱讀 957·2019-08-29 16:31
閱讀 845·2019-08-29 13:10
閱讀 2434·2019-08-27 10:57
閱讀 3152·2019-08-26 13:57