როგორ იღებს Gitlab-CI გარემოს ცვლადებს?

Gitlab-ში ცვლადების დაყენება შესაძლებელია რამდენიმე ადგილას:

1. ჯგუფის პარამეტრებში
2. პროექტის პარამეტრებში
3. შიგნით .gitlab-ci.yml

ამ შემთხვევაში, ჯგუფის და პროექტის პარამეტრებში ცვლადები შეიძლება დაყენდეს როგორც „ფაილი“ ან „ჩვეულებრივი ცვლადი“ და შეამოწმოთ „დაცული“ და „ნიღაბი“ ჩამრთველი.

დავიწყოთ მარტივი მემკვიდრეობით და ის თანდათან უფრო რთული გახდება.

პრიორიტეტების დონეების საბოლოო სია შეგიძლიათ იხილოთ დოკუმენტის ბოლოს.

მემკვიდრეობა ჯგუფებთან ერთად [წყაროები]

ჯგუფებიდან ცვლადები მემკვიდრეობით მიიღება, წესით, რომ რაც უფრო ახლოს არის ჯგუფი პროექტთან, მით უფრო მნიშვნელოვანია მისი ღირებულება.

ჯგუფები ცვლადებით

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

მილსადენის შედეგი

$ echo $MSG
B

თუ ცვლადი არ იყო მითითებული B ჯგუფში, მაშინ ჩვენ დავინახავდით მნიშვნელობას A.

ცვლადების მემკვიდრეობა შიგნით .gitlab-ci.yml [წყაროები]

აქ ყველაფერი საკმაოდ მარტივია: შეგიძლიათ დააყენოთ ცვლადი გლობალურად, ან შეგიძლიათ გადაწეროთ იგი სამუშაოს შიგნით.

ჯგუფები ცვლადებით

.gitlab-ci.yml

მოდით ახლა შევქმნათ 2 სამუშაო ადგილი, ერთ-ერთ მათგანში ჩვენ პირდაპირ მივუთითებთ $MSG.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  Custom in global .gitlab-ci.yml
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  Custom in job .gitlab-ci.yml
  Job succeeded

მემკვიდრეობა ჯგუფებთან და შიგნით .gitlab-ci.yml [წყაროები]

შევეცადოთ გავაერთიანოთ წინა 2 მაგალითი. ჯგუფური ცვლადები უპირატესია .gitlab-ci.yml ცვლადებთან შედარებით.

ჯგუფები ცვლადებით

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  Y
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  Y
  Job succeeded

მემკვიდრეობა პროექტის პარამეტრებში ცვლადების მითითებით [წყაროები]

პროექტის პარამეტრებში ცვლადებს ყოველთვის აქვთ უმაღლესი პრიორიტეტი! და .gitlab-ci.yml შიგნით მითითებული ცვლადები არანაირ როლს არ თამაშობენ.

ჯგუფები ცვლადებით

ჯგუფურ ცვლადებს უფრო დაბალი პრიორიტეტი აქვთ.

.gitlab-ci.yml

მოდით გამოვიყენოთ ფაილი წინა მაგალითიდან. აქ ისევ არის ცვლადები მითითებული .gitlab-ci.yml-ში, მაგრამ ჯგუფების შიგნით ცვლადები მაინც უპირატესობას ანიჭებენ მათზე.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  project-3
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  project-3
  Job succeeded

მემკვიდრეობა ცარიელი ღირებულებით [წყაროები]

ცარიელი მნიშვნელობა ასევე არის მნიშვნელობა
ცარიელი მნიშვნელობა არ არის Null

ჯგუფები ცვლადებით

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  Job succeeded

მემკვიდრეობა მოიცავს და ჯგუფებს [წყაროები]

აქ შევეცდებით პროექტ-2 ჩავრთოთ პროექტ-3-ში
ჯგუფებს ამ შემთხვევაში პრიორიტეტი აქვთ.

ჯგუფები ცვლადებით

.gitlab-ci.yml

და დააყენეთ ცვლადი გლობალურად .gitlab-ci.yml-ში

variables:
 MSG: "With  include  .gitlab-ci.yml"
include:
 - project: how-is-gitlab-ci-inherit-environment-variables/z/y/project-3
   file: '.gitlab-ci.yml'

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  B
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  B
  Job succeeded

მემკვიდრეობა მოიცავს [წყაროები]

აქ შევეცდებით პროექტ-2 ჩავრთოთ პროექტ-3-ში.
იმ პირობით, რომ: არც ჯგუფებს და არც თავად პროექტს არ გააჩნიათ ცვლადები.

ჯგუფები ცვლადებით

.gitlab-ci.yml

იგივე, რაც წინა მაგალითში

variables:
 MSG: "With  include  .gitlab-ci.yml"
include:
 - project: how-is-gitlab-ci-inherit-environment-variables/z/y/project-3
   file: '.gitlab-ci.yml'

მილსადენის შედეგი

• გადაგდება:

  $ echo $MSG
  With include .gitlab-ci.yml
  Job succeeded

• ექო ვარსებით:

  $ echo $MSG
  Custom in job .gitlab-ci.yml
  Job succeeded

შედეგები ასეთია პრიორიტეტები:

1. ცვლადები პროექტის პარამეტრებში
2. ცვლადები ჯგუფებში
3. ცვლადები მკაცრად მითითებული სამუშაოების შიგნით (მათ შორის, ჩართული ფაილები)
4. გლობალური ცვლადები შიგნით .gitlab-ci.yml
5. გლობალური ცვლადები ჩართული ფაილების შიგნით

დასკვნა

ყველაზე ნაკლებად აშკარა ის არის, რომ წესი „რაც უფრო ახლოს არის ცვლადი კოდთან, მით უფრო მნიშვნელოვანია ის“ მუშაობს ჯერ ჯგუფებისთვის, შემდეგ კი იგივე წესი ცვლადებისთვის .gitlab-ci.yml-ში, მაგრამ მხოლოდ იმ პირობით. რომ ჯგუფებში ცვლადები არ არის მითითებული.
შემდეგი, მნიშვნელოვანი პუნქტია იმის გაგება, რომ გლობალური სივრცე ძირითადი და ჩართული .gitlab-ci.yml საერთოა. და ფაილს, რომელშიც ხდება ჩართვა, აქვს პრიორიტეტი.

წყარო: www.habr.com