GitHub集成Circle CI(附 Circle CI 配置示例文件)

GitHub 集成Circle CI

CI(持续集成) 简单解释

CI 即 Continuous Integration. 当代码提交上来有变动的时候，在merge之前自动进行一些流程，如：代码风格检查、单元测试是否通过等。当被merge之后，又会自动进行一些流程，如：自动打包、自动部署至开发、测试环境等。

CIrcle CI 官方对于CI 的解释

CI 工具

常用的CI 工具包括Jenkins、Circle CI、Travis CI. 具体工具孰好孰坏，这里不做深究。

Circle的使用

使用也很简单，只要学会, config.yml文件的书写语法即可

将GitHub项目授权给 Circle CI

1. 在 Circle CI 官网,点击 Go to App,进行GitHub账户授权
   

2. 点击 set up projcet 按钮，将自己的项目和Circle CI 关联
   

书写 config.yml文件

官方配置文档给出了config.yml文件的整体结构，如下图

按照上面的整体结构，下面给出示例文件进行说明：

CI 工作流程基本如下：

从配置的workflows中拿到workflow，查看执行当前workflow需要哪些条件，如果满足，

则执行workflow下的jobs

workflows下的配置很简单：

• version 2 固定为2
• 每一个workflow的名字
  • 该workflow下要执行的jobs名字
  • 对要执行的jobs时机进行配置，可以是基于分支名的正则，也可以是基于分支的定时构建

每个jobs基本由三大步组成：

• 工作目录

• 执行环境 docker\windows\macOS\Linux

• 具体执行步骤 steps

steps常用参数为：

• - checkout 将代码检出至工作目录
• - run 具体执行的命令
  • name 此命令的名字
  • command 具体要执行的命令
  • when 在成功或者失败的时候执行，参数为 on_success 、on_fail
• - restore_cache 在第一次执行的时候会拉取pom文件，如果以后pom文件不发生改变，则不会去拉取，使用原来的下载的依赖，减少时间
• - store_test_results 存储测试结果，当run命令失败的时候，该执行不受其失败的影响还是依旧会执行的

version: 2.1
jobs: # a collection of steps
  # 定义job的名字为【build】 runs not using Workflows must have a `build` job as entry point，
  build:
    # 配置工作目录
    working_directory: ~/repo
    # 执行环境为docker  run the steps with Docker
    docker:
      - image: circleci/openjdk:8-jdk-stretch
      # a collection of executable commands ，当前jobs要执行的具体步骤
    steps:
      # check out source code to working directory 检出源码到工作目录
      - checkout

      - restore_cache: # restore the saved cache after the first run or if `pom.xml` has changed
          # Read about caching dependencies: https://circleci.com/docs/2.0/caching/
          key: v1-repo-{{ checksum "pom.xml" }}
      
      - run:
          name: get dependency
          # 拉取依赖 gets the project dependencies
          command: mvn dependency:go-offline
      
      - save_cache: # saves the project dependencies
          paths:
            - ~/.m2
          key: v1-repo-{{ checksum "pom.xml" }}
      - run:
          name: build start
          command: echo "build start"

      - run:
          name: build project
          # 这里进行打包操作
          command: mvn package
      # 成功时的运行命令
      - run:
          name: bulid success
          command: echo "build success"
          when: on_success
      # 失败时的运行命令
      - run:
          name: build fail
          command: echo "build failur"
          when: on_fail
      # 存储测试结果
      - store_test_results: # uploads the test metadata from the `target/surefire-reports` directory so that it can show up in the CircleCI dashboard. 
        # Upload test results for display in Test Summary: https://circleci.com/docs/2.0/collect-test-data/
            path: target/surefire-reports
        
      - store_artifacts: # store the uberjar as an artifact
        # Upload test summary for display in Artifacts: https://circleci.com/docs/2.0/artifacts/
            path: target/griantBaby-0.0.1-SNAPSHOT.jar
        # See https://circleci.com/docs/2.0/deployment-integrations/ for deploy examples 
workflows:
  version: 2
  # 定义了三个工作流

  # 每次提交时触发
#  commit-workflow:
#    jobs:
#      - build:

  # 当被他人fork时，他人提交PR时进行,使用filter定义 要匹配的branch，only 参数接收一个正则表达式，
  # 一般会和commit-workflow重复，所以这里只保留这个工作流程即可
  fork-commit-workfolw:
    jobs:
      - build:
          filters:
            branches:
              only: /^[A-Za-z0-9].*/
  # 定时触发，由两个部分组成，triggers、要执行的jobs
  scheduled-workfolw:
    triggers:
      - schedule:
           cron: "0 0 * * *"
           filters:
             branches:
               only:
                 - master
    jobs:
      - build

测试 Circle CI 配置文件是否生效

本地dev分支，进行代码修改、暂存、提交、推送远程、向master分支创建PR。当PR创建之后，Circle CI 开始自动进行检查.如下图

在Circle CI控制台同样可以看到，该检查流程

点击某个workflow进入查看详情，这里可以看到，执行的确实docker环境

可以看到，我们上面定义的run的name在这里都显示出来了，点击每一步，还可以查看详情

当失败时，同样可以查看失败的信息，如下图

还可以看到，当jobs执行失败之后，确实执行了我们配置的失败的命令

备注

1. 建议使用时候，参考上述配置文件入门，结合官方文档很容易看懂。如果实在看不懂，不知道怎么写，官方也提供了大量的例子
   

2. 在GitHub上的开源项目本地开发时，单开分支，不要在master分支上进行开发，虽然可能没人用，但是流程一定要是合理的、正常的。如果只有自己开发，大可以开一个dev分支，每次提交，都以PR的方式进行提交。当CI检查通过之后，再merge，养成流程的好习惯

3. 对于Circle CI的深入使用，其实不需要去网上搜索答案，官方文档是最好的答案。文档地址.只要认真看，很容易在文档中找到答案

写在最后

写这篇文章的目的，仅仅是因为最近把GitHub上的项目接入了CI，记录一下。同时希望越来越多的人参与开源，了解开源。

同时本人有一个GitHub的开源项目，目前正缺小伙伴一起开发，如有感兴趣的同学可见项目地址。

期待与你一起开发😄😄😄