2016-05-25 11 views
2

Innerhalb JJB können Sie auf Projektebene Variablen wie folgt definieren:Jenkins Job Builder: Projektebene Variablen

- defaults: 
    name: global 
    git_url: "[email protected]" 

- project 
    name: some-test 
    jobs: 
     - test-{name} 

- job-template 
    name: test-{name} 
    scm: 
     - git: 
      url: "{git_url}" 
      branches: 
      - master 

Meine Frage, muss ich den Wert von git_url auf der Standardebene hart codieren oder kann ich etwas JJB verwenden Mechanismus, um das bei Job-Load/Execution zu bringen?

Der Grund, warum ich frage, ist, dass das YAML-Skript, das diese JJB-Jobs enthält, verwendet werden kann, um TEST, QA und PROD zu definieren. Es wäre schön, auf eine Eigenschaftendatei zu zeigen, die den Wert für git_url und andere globale Variablenwerte enthält. Ich schaute zu: http://docs.openstack.org/infra/jenkins-job-builder/definition.html?highlight=default#defaults und ich sah keinen Mechanismus.

Antwort

2

Wenn ich Ihre Frage richtig verstanden habe, gibt es zwei weitere Ansätze zur Verfügung im Zusammenhang mit einer einzigen yaml Datei

Ansatz 1: Stellen Sie git_url auf Projektebene

- project 
    name: some-test 
    git_url: "[email protected]:woof/bark.git" 
    jobs: 
     - test-{name}: 

- job-template 
    name: test-{name} 
    scm: 
     - git: 
      url: "{git_url}" 
      branches: 
      - master 

Hier git_url wird bei die Projektebene. Dieser Ansatz ermöglicht es Ihnen, für git_url, dh

- project 
    name: some-other-test 
    git_url: "[email protected]:meow/meow.git" 
    jobs: 
     - test-{name}: 

Ansatz 2 ein zweites Projekt mit einem anderen Wert zu definieren: Stellen Sie git_url am Job-Vorlage Instanzebene

- project 
    name: some-test 
    jobs: 
     - test-{name}: 
     git_url: "[email protected]" 

- job-template 
    name: test-{name} 
    scm: 
     - git: 
      url: "{git_url}" 
      branches: 
      - master 

Hier git_url auf dem tatsächlichen gesetzt Instanz der Job-Vorlage, in der sie angegeben ist. Wenn Ihre job-template in seinem Namen mehr als nur {name} hatte, würde dies ermöglicht es Ihnen, mehrere Instanzen in der Liste der jobs auf Projektebene, dh

- project 
    name: some-test 
    git_url: "[email protected]" 
    jobs: 
     - test-{name}-{type}: 
     type: 'cat' 
     - test-{name}-{type}: 
     type: 'dog' 

- job-template 
    name: test-{name}-{type} 
    display-name: 'Test for {type} projects' 
    scm: 
     - git: 
      url: "{git_url}" 
      branches: 
      - master 

Gedanken über TEST vs QA vs ART

zu erstellen

Sie haben auch erwähnt, dass Sie eine Datei mit externen Eigenschaften wünschen, um zwischen TEST-, QA- und PROD-Umgebungen zu unterscheiden. Um dies anzugehen, betrachten wir vier verschiedene Dateien, project.yaml, defaults/TEST.yaml, defaults/QA.yaml, defaults/PROD.yaml, deren Inhalt unten aufgezählt wird.

project.yaml

- project 
    name: some-test 
    jobs: 
     - test-{name}: 

defaults/TEST.yaml

- defaults: 
    name: global 
    git_url: "[email protected]:woof/test.git" 

defaults/QA.yaml

- defaults: 
    name: global 
    git_url: "[email protected]:woof/qa.git" 

defaults/PROD.yaml

- defaults: 
    name: global 
    git_url: "[email protected]:woof/prod.git" 

Okay, so sind diese nicht gute Beispiele, weil Sie wahrscheinlich nicht ein anderes Git Repository für jede Umgebung haben würden, aber ich will nicht Dinge komplizieren, indem zu weit verirrt von Ihrem Originalbeispiel.

Mit JJB können Sie mehr als eine YAML-Datei in der Befehlszeile angeben (ich möchte das Beispiel oder seine Erklärung nicht komplizieren, aber Sie können auch Verzeichnisse angeben, die voll von JJB-yaml sind). Zur Unterscheidung zwischen TEST, QA und ART-Implementierungen Ihres Jenkins Jobs können Sie dann so etwas wie:

jenkins-jobs project.yaml:defaults/TEST.yaml 

Für Ihre Testumgebung.

jenkins-jobs project.yaml:defaults/QA.yaml 

Für Ihre Qa-Umgebung.

jenkins-jobs project.yaml:defaults/PROD.yaml 

Für Ihre Produktumgebung.

Hoffe, dass hilft.