GitLab Continuous Integration(CI)
If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your Gitlab project to use a Runner, then each merge request or push trigger your CI pipeline.
The .gitlab-ci.yml file tells the Gitlab runner what to do. By default it runs a pipeline with threes stages: build, test, and deploy. You don’t need to use all three stages; stages with no jobs are simply ignored.
If everything runs ok (no non-zero return values), you will get a nice green checkmark associated with the pushed commit or merge request.
Most projects use Gitlab’s CI service to run the test suite so that developers get immediate feedback if they broken something.
There’s 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:
Add .gitlab-ci.yml to the root directory of your repository
Configure a Runner
From there on, on every push to your Git resposity, the Runner will automagically start the pipeline and the pipeline will appear under there projects’ /pipelines page.
This guide assumes that you:
have a working Gitlab instance of version 8.0 or higher or are using 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.
Creating a .gitlab-ci.yml file
What is .gitlab-ci.yml
The .gitlab-ci.yml file is where you configure what CI does with your project. It lives in the root of your repository.
On any push to your repository, GitLab will look for the .gitlab-ci.yml file and start builds on Runners according to the contents of the file, for that commit.
Because .gitlab-ci.yml is in the repository and is version controlled, old versions still build successfully, forks can easily make use of CI, branches can have different pipelines and jobs, and you have a single source of truth for CI.
Note: .gitlab-ci.yml is a YAML file so you have pay extra attention to indentation. Always use spaces, not tabs.
If you want to check whether your .gitlab-ci.yml file is valid, there is a Lint tool under the page ?ci/lint of your GitLab instance. You can also find there link under Settings > CI settings in your project.
For more information and a complete .gitlab-ci.yml syntax, please read http://doc.gitlab.com/ce/ci/yaml/README.html
Push .gitlab-ci.yml to GitLab
Once you’ve created .gitlab-ci.yml, you should add it to your repository and push it to GitLab.
git add .gitlab-ci.yml
git commit -m “Add .gitlab-ci.yml”
git push origin master
Now if you go to the Pipelines page you will see that pipeline is pending.
You can also go to the Commits page and notice the little clock icon next to the commit SHA.
Clicking on the rock you will be directed to the builds page for that specific commit.
Notice that there are two jobs pending which are named after what we wrote in .gitlab-ci.yml. The red triangle indicates that there is no Runner configured yet for these builds.
The next step is to configure a Runner so that it picks the pending builds.
In GitLab, Runners run the builds that you define in .gitlab-ci.yml. A Runner can be a virtual machine, a VPS, a bare-metal machine, a docker container or even a cluster of containers. GitLad and the Runners communicate through an API, so the only requirement is that the Runner’s machine has Internet access.
A Runner can be specific to a certain project or serve multiple projects in GitLab. If ti serves all projects it’s called a Shared Runner.
Find more information about Runner from this link : http://doc.gitlab.com/ce/ci/runners/README.html
#Install gitlab-ci-multi-runner#
GitLab Continuous Integration Server
ssh gci.xq.cn -l james
Install Docker runner:
curl -sSL https://get.docker.com/ | sh
Error reporting -
curl: (6) Could not resolve host: get.docker.com; Unknown error
cat /etc/resolv.conf
Generated by NetworkManager
search xq.cn
No nameservers found; try putting DNS servers into your
ifcfg files in /etc/sysconfig/network-scripts like so:
DNS1=xxx.xxx.xxx.xxx
DNS2=xxx.xxx.xxx.xxx
DOMAIN=lab.foo.com bar.foo.com
Add nameserver 8.8.8.8 to resolv.conf
Execute : curl -sSL https://get.docker.com/ | sh
Ok. Done.
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
sudo wget -O /usr/local/bin/gitlab-ci-multi-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-linux-386
创建一个项目，并查看项目的 Runner
创建项目 －》 Setting －》Runner
Specific runners
How to setup a new project specific runner
Install GitLab Runner software. Checkout the GitLab Runner section to install it
Specify following URL during runner setup: http://git.xq.cn/ci
Use the following registration token during setup: St8Crygwy6sc75jqqw-y
Start runner!
使用 Runner
在项目根目录下，创建 .gitlab-ci.yml
内容如下：
before_script:
- sudo composer global require "laravel/installer"
init_jog:
script:
- touch test.php
在执行脚本之前，先去安装 laravel 框架。然后，再去执行工作 init_jog，这个工作也就是简单创建一个 test.php 脚本 。
git push origin master 之后，
到 GitLab 项目管理页面，查看 “Builds” ，
如何检查 yml 文件的语法
GitLab CI Issues
一
Build always pending
Summary: GitLab CI does not start building of jobs, it is always pending.
Steps to reproduce: Install GitLab CI 7-10-stable, add a runner, add a repo, commit to the repo
Expected behavior: GitLab CI should trigger the runner and the runner should start to build
Observed behavior GitLab CI recognizes the commit and says build is pending, but does not trigger the runner. It says, that the last contact to the runner was never.
Relevant logs and/or screenshots: Every 5 Seconds in production.log: Started POST "/api/v1/builds/register.json" for 127.0.0.1 at 2015-04-27 05:08:48 +0200
