Customizando pipelines usando scripts customizados

Configuração em pipeline-config.yaml

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

Localização do arquivo

Para pipelines de pull request e integração contínua, armazene o arquivo de configuração .pipeline-config.yaml em um repositório de aplicativos da mesma forma que os arquivos .travis.yml ou Jenkinsfile. Para pipelines de implantação contínua, armazene esse 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 extrair a configuração e os scripts. O valor padrão é o repositório de aplicativos de integração contínua.
• pipeline-config-branch para usar como o ramo da configuração no repositório de configuração. O valor padrão é a ramificação do repositório de aplicativos de integração contínua e a ramificação 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 é usado como um arquivo de script, certifique-se de que o conteúdo funcione como um arquivo de script na imagem de 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 do pod ImagePullPolicy que é fornecida na imagem para a imagem de 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 é 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 do segredo está localizado no configmap de propriedades do ambiente 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
    ...