Konfiguration in .pipeline-config.yaml

Verwenden Sie eine Konfigurationsdatei .pipeline-config.yaml, um das Verhalten der Pipeline zu erweitern.

Dateiposition

Speichern Sie für Pull-Requests und Continuous-Integration-Pipelines die .pipeline-config.yaml Konfigurationsdatei in einem App-Repository auf dieselbe Weise wie die .travis.yml Dateien Jenkinsfile oder. Speichern Sie diese Datei für Continuous-Deployment-Pipelines in einem eigenen Repository.

Für alle Pipeline-Arten gilt, dass Sie die Position und Quelle der Datei .pipeline-config.yaml mit den folgenden Parametern der Pipeline-Benutzerschnittstelle (UI) anpassen können:

• pipeline-config: Dient zum Festlegen des Pfads der Konfigurationsdatei. Der Standardwert ist .pipeline-config.yaml.
• pipeline-config-repo um das Repository festzulegen, aus dem die Konfiguration und die Skripte abgerufen werden sollen. Der Standardwert ist das Repository der Continuous-Integration-App.
• pipeline-config-branch als Zweig für die Konfiguration im Konfigurations-Repository zu verwenden. Der Standardwert ist der Zweig des App-Repositorys für die kontinuierliche Integration sowie der Zweig master für die kontinuierliche Bereitstellung.

Konfigurationsparameter

Die Konfiguration in der Datei .pipeline-config.yaml unterstützt die folgenden Parameter:

Bei diesen Einstellungen handelt es sich nicht um Pipeline-Parameter, sondern sie müssen Teil Ihrer Datei .pipeline-config.yaml sein.

• image: Sie können jedes Docker-Image, auf das der Pipeline-Worker zugreifen kann, als Basisimage für die Task verwenden.

• script: Das Script, das in der Stage ausgeführt werden soll. Da dieses Feld als Skriptdatei verwendet wird, stellen Sie sicher, dass der Inhalt in dem von Ihnen bereitgestellten Basis-Image wie eine Skriptdatei funktioniert. Neben dieser Konfigurationsdatei können Sie weitere Scripts einschließen und von diesem Einstiegspunkt aus auf sie verweisen. Zum Beispiel:

test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    scripts/lint.sh
    scripts/unit-test.sh

• dind: Geben Sie an, ob für den Scriptkontext docker-in-docker aktiviert werden soll. Die Standardeinstellung ist false.

• abort_on_failure: Wenn das Script fehlschlägt, wird standardmäßig die Pipeline gestoppt. Wenn Sie diese Option auf false setzen, wird die Phase in einer Warnung (bernsteinfarben) markiert (sie wurde mit einer Warnung übergeben), die Pipeline kann fortgesetzt werden und der fehlgeschlagene Job wird in den Angaben referenziert.

• image_pull_policy: Legen Sie die Pod-Einstellung ImagePullPolicy fest, die im Image für das Basis-Image bereitgestellt wird. Mögliche Werte sind mit den gültigen Werten für Kubernetes deckungsgleich: Always oder IfNotPresent. Der Standardwert ist IfNotPresent.

• configmap: Extrahieren Sie Schlüssel/Wert-Paare aus einer angegebenen Konfigurationszuordnung, auf die über PipelineRun zugegriffen werden kann. Die folgenden Werte werden unterstützt:

  • config-name: Die Syntax des Namens der direkten Konfigurationszuordnung. Der Stage-Runner versucht, auf die Konfigurationszuordnung namens config-namezuzugreifen und diese per Mount anzuhängen.
  • $prop-name: Die Syntax des Namens der indirekten Konfigurationszuordnung. Der Name der Konfigurationszuordnung wird der Konfigurationszuordnung 'environment-properties' -Configmap entnommen, die alle Umgebungswerte enthält, die in der Pipeline-Benutzerschnittstelle (UI) festgelegt sind. Wenn beispielsweise in den Umgebungseigenschaften ein my-config Eintrag prop vorhanden ist, my-config wird für verwendet $prop.

• secret: Extrahieren Sie Schlüssel/Wert-Paare aus einer angegebenen Konfigurationszuordnung, auf die über PipelineRun zugegriffen werden kann. Die folgenden Werte werden unterstützt:

  • secret-name: Die Syntax des direkten Namens des geheimen Schlüssels. Der Stage-Runner versucht, auf den geheimen Schlüssel namens secret-namezuzugreifen und diesen per Mount anzuhängen.

  • $prop-name: Die Syntax des indirekten geheimen Schlüssels. Der Secret-Name befindet sich in der ConfigMap environment-properties, die alle Umgebungswerte enthält, die in der Pipeline-Benutzeroberfläche festgelegt wurden. Wenn die Konfigurationszuordnung 'environment-properties' zum Beispiel die Eigenschaft my-secret enthält, wird my-secret für $propverwendet.

• runAfter: Die aktuelle Phase wird nach Abschluss der in dieser Eigenschaft angegebenen Phase ausgeführt. Legen Sie den Wert mit dem Phasennamen fest, den Sie in .pipeline-config.yaml verwendet haben. Verwenden Sie diese Eigenschaft sparsam und bestätigen Sie, dass die durch diese Eigenschaft angegebene Stage in der Pipeline vorhanden ist. Wenn die Stage nicht vorhanden ist, kann die Pipeline in einen Deadlock übergehen.

• skip: Wenn auf true gesetzt, wird die aktuelle Phase (sofern möglich) in v10-Pipelines umgangen. Nicht alle Phasen können umgangen werden. In der folgenden Tabelle sind die Phasen aufgelistet, die während der Pipelineausführung übersprungen werden können.

version: '1' # fixed, this value is used to track schema changes
# `setup` runs right after the app repo is cloned
setup:
  # the pipeline will break in case setup fails (default is true)
  abort_on_failure: true
  # any docker image can be used which is accessible by the private worker
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # you can reference configmaps, each key in the configmap is going to be available as `/config/{key}`
  configmap: my-config
    # `$prop` is the indirect config map syntax, the concrete configmap is looked
    # up from the `environment-properties` configmap
    #
    # Eg. if there's a `prop: my-config` entry in the environment properties,
    # then `my-config` is going to be used for `$prop`
  configmap: $prop
  # the mechanism described works for secrets as well!
  secret: $my-secrets
  # the script is executed inside the checked out app repo
  script: |
    #!/bin/sh
    ...
# `test` runs after `setup`, but before building the docker image
test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...
# `static-scan` runs after `test`, but before building the docker image
static-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `deploy` runs after building the docker image
deploy:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # the script has access to the built docker image, which is available at `/config/image`
  script: |
    #!/bin/sh
    cat /config/image
# `dynamic-scan` runs after `deploy`, but before the acceptance test run
dynamic-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `acceptance-test` runs after `deploy`
acceptance-test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...