Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use Gitlab Template to enhance the scalability and compatibility of GitLab CICD

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/01 Report--

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!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report