How to use Gitlab Template to enhance the scalability and compatibility of GitLab CICD
This article mainly explains "how to use Gitlab Template to enhance the extensibility and compatibility of GitLab CICD". The explanation content in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian slowly and deeply to study and learn "how to use Gitlab Template to enhance the extensibility and compatibility of GitLab CICD" together!
Include directive
Func: Used to import YAML files ending in.yml or.yaml, other types of files cannot be imported. We can use include to make the structure of the.gitlab-ci.yml file clearer, and we can also write some jobs that need centralized management and maintenance in a YAML file, put them in a common repository, and let CI of other projects introduce the file.
For example, if each team needs to execute a report job to report release related information, we can write this job in a report.yml file, put it in a common repository, and then import each team's.gitlab-ci.yml file into report.yml. If you need to add something to report later, you only need to modify the report.yml of the public project. Of course, since report.yml will be referenced by multiple projects, it must be universal and have good extensibility and compatibility. If you change something, it will be worse if every team needs to cooperate with you.
include Note Suppose the template file example.yml contains the following:
variables:
POSTGRES_USER: user
POSTGRES_PASSWORD: testing_password
POSTGRES_DB: $CI_ENVIRONMENT_SLUG
production:
stage: production
script:
- install_dependencies
- deploy
environment:
name: production
url: https://$CI_PROJECT_PATH_SLUG.$ KUBE_INGRESS_BASE_DOMAIN
only:
- master
.gitlab-ci.yml reads:
include: 'example.yml'
image: alpine:latest
variables:
POSTGRES_USER: root
POSTGRES_PASSWORD: secure_password
stages:
- build
- test
- production
production:
environment:
url: https://domain.com
If the included file and.gitlab-ci.yml define the same variable in variable, that variable is overridden by the variable defined in.gitlab-ci.yml. In the example above, the value of the variable in the final example.yml is: POSTGRES_USER: root
POSTGRES_PASSWORD：secure_password
POSTGRES_DB: $CI_ENVIRONMENT_SLUG
If both the included file and.gitlab-ci.yml define the same job, the two jobs will be merged. In the above example, the enviroment url value of production job in example.yml is https://domain.com
In addition, include can also use the keyword template to introduce the.gitlab-ci.yml template, more detailed information can be read in the official documentation.
Extensions command
Func: extensions replaced? YAML Anchors are readable and more flexible. It defines a template that can be inherited by the job, so that we can abstract some common keys to facilitate future maintenance and extension.
Example：
.tests:
script: rake test
stage: test
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
only:
variables:
- $RSPEC
Result：
rspec:
script: rake rspec
stage: test
only:
refs:
- branches
variables:
- $RSPEC
The above is the official example: tests as a template, rspec to inherit it, if both have the same key, then use the value of the child to override the parent class.
For more information on extension, please read: gitlab-ci extends
include and extend
Include and extends support are used together. If only include, we can only let a project reference a YAML file, and then trigger the corresponding job according to mediation, and after adding extend, we can also manage some common properties or methods (mainly Script) uniformly. This allows us to better abstract and unify maintenance.
Example：
B.ymlvariables:
TEST_VAR: B
.template:
stage: test
only:
- master
script:
- echo_hello
- echo "VAR1 = ${VAR1}"
- echo "VAR2 = ${VAR2}"
- echo "TEST_VAR = ${TEST_VAR}"
.gitlab-ci.ymlvariables:
TEST_VAR: A
include:
- B.yml
job_a:
before_script:
- |
function echo_hello(){
echo "hello world! "
}
- VAR1="hello"
- VAR2="world"
extends: .template
only:
variables:
- $A
When the master branch updates or defines the A variable, CI is triggered, and the execution results:
hello world!
VAR1 = hello
VAR2 = world
TEST_VAR = A
The above results indicate that:
The job executed in.gitlab-ci.yml uses the environment variables defined in the.gitlab-ci.yml file, so the action of outputting TEST_VAR = Aextends is earlier than before_script Thank you for reading. The above is the content of "How to use Gitlab Template to enhance the extensibility and compatibility of GitLab CICD". After studying this article, I believe everyone has a deeper understanding of how to use Gitlab Template to enhance the extensibility and compatibility of GitLab CICD. The specific use situation also needs everyone to practice verification. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!
