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

ഗ്രൂപ്പ് ബിയിൽ വേരിയബിൾ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, നമ്മൾ മൂല്യം എ കാണുമായിരുന്നു.

.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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ 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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ 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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ echo $MSG
  project-3
  Job succeeded

ശൂന്യമായ മൂല്യമുള്ള അനന്തരാവകാശം [ഉറവിടങ്ങൾ]

ഒരു ശൂന്യമായ മൂല്യവും ഒരു മൂല്യമാണ്
ഒരു ശൂന്യമായ മൂല്യം ശൂന്യമല്ല

വേരിയബിളുകളുള്ള ഗ്രൂപ്പുകൾ

.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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ 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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ 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

• vars ഉപയോഗിച്ച് പ്രതിധ്വനിക്കുക:

  $ 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