One of the illusions that programmers at big companies easily fall into is mistaking platform capabilities for their own abilities. In a large team, we should not focus only on our own little patch of ground; we need to understand every part of the platform. On one hand, this helps us make better use of the platform’s features; on the other, it helps our own technical growth.

Using GitLab issues for project management is a very Dev-friendly thing. Entering issues, opening Merge Requests, creating milestones — these all advance dynamically during development. But creating a pile of Labels for every new project is a headache. This article is mainly about solving that problem. 1. GitLab Label Before

Because I am responsible for the team’s shared CI matters, I often need to configure CI pipelines or help others solve problems, so I put together the CI scripts I use most often for easy reference. 1. Structure of .gitlab-ci.yml Below is the structure of a GitLab CI configuration file.

1. Downloading and Configuring the Runner 1.1 Downloading the Runner The GitLab CI Runner is a program package written in Go; you can download it from the official site to your local machine. 1 2 yum install -y wget wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 Add execute permission 1 chmod +x /usr/local/bin/gitlab-runner 1.

Starting with GitLab 8.0, GitLab began integrating CI (Continuous Integration) functionality. You only need to add a Runner on the server and a .gitlab-ci.yml file in the project, and you can run CI. In GitLab Setup and Configuration I recorded the whole process of setting up a GitLab service from