Die gleichen Schritte für mehrere benannte Umgebungen mit GitLab CI

Question

Gibt es eine Möglichkeit, mehrere spezifisch benannte Umgebungen zu konfigurieren (speziell test, stage und)?

In ihrer Dokumentation (https://docs.gitlab.com/ce/ci/environments.html) sprechen sie über dynamisch erstellte Umgebungen, aber sie sind alle commit-basiert.

Meine Build Schritte sind die gleichen für alle von ihnen, die Schnecke zum Auslagern sparen:

deploy_to_test: 
    environment: 
     name: test 
     url: ${CI_ENVIRONMENT_SLUG}.mydomain.com 
    scripts: 
     - deploy ${CI_ENVIRONMENT_SLUG} 

deploy_to_stage: 
    environment: 
     name: stage 
     url: ${CI_ENVIRONMENT_SLUG}.mydomain.com 
    scripts: 
     - deploy ${CI_ENVIRONMENT_SLUG} 

deploy_to_prod: 
    environment: 
     name: prod 
     url: ${CI_ENVIRONMENT_SLUG}.mydomain.com 
    scripts: 
     - deploy ${CI_ENVIRONMENT_SLUG} 

Gibt es eine Möglichkeit, dies von Anweisungen nach unten in einen Satz zu komprimieren? Etwas wie:

deploy: 
    environment: 
     url: ${CI_ENVIRONMENT_SLUG}.mydomain.com 
    scripts: 
     - deploy ${CI_ENVIRONMENT_SLUG} 

Answer 1

Ja, Sie können anchors verwenden. Wenn ich die Dokumentation richtig befolge, schreibe ich sie mit einem versteckten Schlüssel .XX um und verwende ihn dann mit <<: *X.

Zum Beispiel diese den Schlüssel zu definieren:

.job_template: &deploy_definition 
    environment: 
     url: ${CI_ENVIRONMENT_SLUG}.mydomain.com 
    scripts: 
     - deploy ${CI_ENVIRONMENT_SLUG} 

Und dann können alle Blöcke writen werden <<: *job_template verwenden. Ich nehme an, environment wird den Namen mit der vordefinierten URL zusammenführen.

deploy_to_test: 
    <<: *job_definition 
    environment: 
     name: test 

deploy_to_stage: 
    <<: *job_definition 
    environment: 
     name: stage 

deploy_to_prod: 
    <<: *job_definition 
    environment: 
     name: prod 

---

Voll docs Abschnitt aus dem obigen Link:

YAML hat eine praktische Funktion 'Anker' genannt, die Sie leicht doppelten Inhalte in Ihrem Dokument kann. Anker können zum Vervielfältigen/Vererben von Eigenschaften verwendet werden und sind ein perfektes Beispiel für die Verwendung von verborgenen Schlüsseln, um Vorlagen für Ihre Jobs bereitzustellen.

Im folgenden Beispiel werden Anker und Map-Merging verwendet. Es wird zwei Arbeitsplätze schaffen, test1 und test2, dass die Parameter von .job_template erben werden, die jeweils ihre eigenen benutzerdefinierten Skript definiert haben:

.job_template: &job_definition # Hidden key that defines an anchor named 'job_definition' 
    image: ruby:2.1 
    services: 
    - postgres 
    - redis 

test1: 
    <<: *job_definition   # Merge the contents of the 'job_definition' alias 
    script: 
    - test1 project 

test2: 
    <<: *job_definition   # Merge the contents of the 'job_definition' alias 
    script: 
    - test2 project 

& setzt den Namen des Ankers (job_definition) nach oben, < < Mittel " füge den gegebenen Hash in den aktuellen Hash ein "und * enthält den benannten Anker (Job_Definition erneut). Die erweiterte Version sieht wie folgt aus:

.job_template: 
    image: ruby:2.1 
    services: 
    - postgres 
    - redis 

test1: 
    image: ruby:2.1 
    services: 
    - postgres 
    - redis 
    script: 
    - test1 project 

test2: 
    image: ruby:2.1 
    services: 
    - postgres 
    - redis 
    script: 
    - test2 project 

Answer 2

Außer dem, was die Antwort angeboten, würde Ich mag eine ähnliche Art und Weise hinzuzufügen Art von der gleichen Sache zu erreichen, aber es ist flexibler, anstatt eine Vorlage zu verwenden und dann füge es in einer Phase zusammen.

Sie können auch einen versteckten Schlüssel erstellen, aber in diesem Format, z.

,

.login: &login | 
    cmd1 
    cmd2 
    cmd3 
    ... 

Und dann können Sie es auf verschiedene Stufen anwenden, indem Sie das '*' verwenden, das Sternchen, wie:

deploy: 
    stage: deploy 
    script: 
    - ... 
    - *login 
    - ... 

bake: 
    stage: bake 
    script: 
    - ... 
    - *login 
    - ... 

Und das Ergebnis wäre gleichbedeutend mit:

deploy: 
    stage: deploy 
    script: 
    - ... 
    - cmd1 
    - cmd2 
    - cmd3 
    - ... 

bake: 
    stage: bake 
    script: 
    - ... 
    - cmd1 
    - cmd2 
    - cmd3 
    - ... 

Basiert auf der Ressource von: https://gitlab.com/gitlab-org/gitlab-ce/issues/19677#note_13008199

Wie für die Vorlagenimplementierung ist es "zusammengeführt". Wenn Sie nach dem Zusammenführen einer Vorlage weitere Skripts anhängen, werden nach eigener Erfahrung die Vorlagenskripte überschrieben. Und Sie können nicht mehrere Vorlagen gleichzeitig anwenden. Nur die letzten Vorlagenskripte werden ausgeführt. Zum Beispiel:

.tmp1: &tmp1 
    script: 
    - a 
    - b 

.tmp2: &tmp2 
    script: 
    - c 
    - d 

job1: 
    <<: *tmp1 
    <<: *tmp2 
    stage: xxx 

job2: 
    <<: *tmp2 
    stage: yyy 
    script: 
    - e 
    - f 

Das äquivalente Ergebnis wäre:

job1: 
    stage: xxx 
    script: 
    - c 
    - d 

job2: 
    stage: yyy 
    script: 
    - e 
    - f 

Wenn über die Syntax Richtigkeit nicht sicher, kopieren Sie einfach und fügen Sie Ihren .gitlab.yml Dateiinhalt „CI Lint“ zu validieren. Die Schaltfläche befindet sich in der Registerkarte Pipelines.