Configurazione in .pipeline-config.yaml

Utilizzare un file di configurazione .pipeline-config.yaml per estendere il comportamento della pipeline.

Ubicazione file

Per le pipeline di integrazione continue e di richiesta di pull, archivia il file di configurazione .pipeline-config.yaml in un repository dell'applicazione nello stesso modo dei file .travis.yml o Jenkinsfile. Per le pipeline di distribuzione continue, memorizzare questo file in un repository dedicato.

Per tutte le pipeline, è possibile personalizzarne l'ubicazione e l'origine del file .pipeline-config.yaml con i seguenti parametri dell'IU della pipeline:

• pipeline-config per impostare il percorso del file di configurazione. Il valore predefinito è .pipeline-config.yaml.
• pipeline-config-repo per impostare il repository da cui estrarre la configurazione e gli script. Il valore predefinito è il repository dell'applicazione di integrazione continua.
• pipeline-config-branch da utilizzare come ramo per la configurazione nel repository di configurazione. Il valore predefinito è il ramo del repository dell'applicazione di integrazione continua e il ramo master nella distribuzione continua.

Parametri di configurazione

La configurazione nel file .pipeline-config.yaml supporta i parametri seguenti:

Queste impostazioni non sono parametri pipeline, ma devono far parte del tuo file .pipeline-config.yaml.

• image: puoi utilizzare qualsiasi immagine Docker a cui il nodo di lavoro della pipeline può accedere come immagine di base per l'attività.

• script: lo script da eseguire nella fase. Poiché questo campo viene utilizzato come un file script, assicurarsi che il contenuto agisca come un file script nell'immagine di base fornita. È possibile includere altri script accanto a questo file di configurazione e fare riferimento ad essi da questo punto di ingresso. Ad esempio:

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

• dind: specificare se abilitare docker-in-docker per il contesto di script. L'impostazione predefinita è false.

• abort_on_failure: per impostazione predefinita, la pipeline si arresta quando lo script non riesce. L'impostazione di questo valore su false contrassegna lo stage in uno stato di avvertenza (ambra) (passato con avvertenza), consente alla pipeline di continuare e si fa riferimento al job non riuscito nella prova.

• image_pull_policy: imposta l'impostazione del pod ImagePullPolicy fornita nell'immagine per l'immagine di base. I valori possibili sono uguali ai valori validi per Kubernetes: Always o IfNotPresent. Il valore predefinito è IfNotPresent.

• configmap: eseguire il pull delle coppie chiave - valore da una configmap fornita accessibile da PipelineRun. Sono supportati i seguenti valori:

  • config-name: la sintassi del nome della configmap diretta. Il programma di esecuzione dello stage tenta di accedere e montare la configmap denominata config-name.
  • $prop-name: la sintassi del nome della configmap indiretta. Il nome della mappa di configurazione viene ricercato dalla mappa di configurazione delle proprietà dell'ambiente, che contiene ogni valore di ambiente impostato sulla UI della pipeline. Ad esempio, se è presente una voce prop my-config nelle proprietà dell'ambiente, my-config viene utilizzata per $prop.

• secret: eseguire il pull delle coppie chiave - valore da una configmap fornita accessibile da PipelineRun. Sono supportati i seguenti valori:

  • secret-name: la sintassi del nome segreto diretto. Il programma di esecuzione dello stage tenta di accedere e montare il segreto denominato secret-name.

  • $prop-name: la sintassi del nome segreto indiretto. Il nome segreto si trova nella mappa di configurazione delle proprietà dell'ambiente che contiene ogni valore di ambiente impostato nell'IU della pipeline. Ad esempio, se la configmap environment - properties contiene la proprietà della voce my-secret, my-secret viene utilizzato per $prop.

• runAfter: eseguire la fase corrente dopo il completamento della fase specificata in questa proprietà. Imposta il valore con il nome stage che hai utilizzato in .pipeline-config.yaml. Utilizzare questa proprietà con parsimonia e confermare che lo stage specificato da questa proprietà esiste nella pipeline. Se la fase non esiste, la pipeline può entrare in un deadlock.

• skip: se impostato su true, ignora la fase corrente, se possibile, nelle pipeline v10. Non tutte le fasi possono essere ignorate. La seguente tabella elenca le fasi che possono essere ignorate durante l'esecuzione della pipeline.

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
    ...