Configuração em .pipeline-config.yaml

Use um arquivo de configuração do tipo “ .pipeline-config.yaml ” para ampliar o comportamento do pipeline.

Localização do arquivo

Para pull requests e pipelines de integração contínua, armazene o arquivo de configuração .pipeline-config.yaml em um repositório de aplicativo, da mesma forma que os arquivos .travis.yml`` ou Jenkinsfile . Para pipelines de implantação contínua, armazene este arquivo em um repositório dedicado.

Para todos os pipelines, é possível customizar o local e a origem do arquivo .pipeline-config.yaml, usando os seguintes parâmetros da IU do pipeline:

• pipeline-config para definir o caminho do arquivo de configuração. O valor padrão é .pipeline-config.yaml.
• pipeline-config-repo para definir o repositório do qual a configuração e os scripts serão baixados. O valor padrão é o repositório do aplicativo de integração contínua.
• pipeline-config-branch para ser usado como o branch da configuração no repositório de configuração. O valor padrão é o branch do repositório do aplicativo na integração contínua e o branch master na implantação contínua.

Parâmetros de configuração

A configuração no arquivo .pipeline-config.yaml suporta os seguintes parâmetros:

Essas configurações não são parâmetros de pipeline, elas devem fazer parte do arquivo .pipeline-config.yaml.

• image: é possível usar como imagem de base para a tarefa qualquer imagem do Docker que seja acessível para o trabalhador do pipeline.

• script: o script a ser executado no estágio. Como esse campo é utilizado como um arquivo de script, certifique-se de que o conteúdo funcione como um arquivo de script na imagem base que você forneceu. Outros scripts podem ser incluídos próximos a este arquivo de configuração e podem ser referenciados a partir deste ponto de entrada. Por exemplo:

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

• dind: especifique se docker-in-docker será ativado para o contexto de script. A configuração padrão é false.

• abort_on_failure: por padrão, o pipeline é interrompido em caso de falha no script. Configurar isso como false marca o estágio em um aviso (estado âmbar) (ele passou com aviso), permite que o pipeline continue e a tarefa com falha é referenciada na evidência...

• image_pull_policy: Defina a configuração “ ImagePullPolicy ” do pod, conforme indicado na imagem, para a imagem base. Os valores possíveis são os mesmos valores válidos para o Kubernetes: Always ou IfNotPresent. O valor padrão é IfNotPresent.

• configmap: obter pares de valores de chave a partir de um configmap fornecido que pode ser acessado por PipelineRun. Os valores a seguir são suportados.

  • config-name: a sintaxe direta do nome do configmap. O executor do estágio tenta acessar e montar o mapa de configuração chamado config-name.
  • $prop-name: a sintaxe indireta do nome do configmap. A consulta do nome do configmap é feita a partir do configmap environment-properties, que contém cada valor de ambiente configurado na IU do pipeline. Por exemplo, se houver uma entrada “prop my-config ” nas propriedades do ambiente, então “ my-config ” será usado para “ $prop ”.

• secret: obter pares de valores de chave a partir de um configmap fornecido que pode ser acessado por PipelineRun. Os valores a seguir são suportados.

  • secret-name: a sintaxe direta do nome do segredo. O executor do estágio tenta acessar e montar o segredo chamado secret-name.

  • $prop-name: a sintaxe indireta do nome do segredo. O nome “Secret” está localizado no configmap “environment-properties”, que contém todos os valores de ambiente definidos na interface do usuário do pipeline. Por exemplo, se o configmap environment-properties contiver a propriedade my-secret, my-secret será usado para $prop.

• runAfter: execute o estágio atual após o estágio especificado nesta propriedade ser concluído.. Configure o valor com o nome do estágio usado em .pipeline-config.yaml. Use essa propriedade com moderação e confirme se o estágio especificado por essa propriedade existe no pipeline.. Se o estágio não existir, o pipeline poderá entrar em um conflito

• skip: se configurado como true, ignore o estágio atual, se possível, em pipelines v10. Nem todos os estágios podem ser contornadas. A tabela a seguir lista os estágios que podem ser ignorados durante a execução do 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
    ...