2.8. Déclenchement et modification des constructions

Les déclencheurs Webhook vous permettent de déclencher une nouvelle construction en envoyant une demande au point d'extrémité API de OpenShift Container Platform. Vous pouvez définir ces déclencheurs en utilisant GitHub, GitLab, Bitbucket ou Generic webhooks.

Actuellement, les webhooks d'OpenShift Container Platform ne supportent que les versions analogues de l'événement push pour chacun des systèmes de gestion de code source (SCM) basés sur Git. Tous les autres types d'événements sont ignorés.

Lorsque les événements push sont traités, l'hôte du plan de contrôle d'OpenShift Container Platform confirme si la référence de la branche à l'intérieur de l'événement correspond à la référence de la branche dans le BuildConfig correspondant. Si c'est le cas, il vérifie alors la référence exacte du commit noté dans l'événement webhook sur le build d'OpenShift Container Platform. S'ils ne correspondent pas, aucun build n'est déclenché.

Pour tous les webhooks, vous devez définir un secret avec une clé nommée WebHookSecretKey et la valeur à fournir lors de l'invocation du webhook. La définition du webhook doit ensuite faire référence au secret. Le secret garantit l'unicité de l'URL, empêchant ainsi d'autres personnes de déclencher la construction. La valeur de la clé est comparée au secret fourni lors de l'invocation du webhook.

Par exemple, voici un webhook GitHub avec une référence à un secret nommé mysecret:

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

Le secret est alors défini comme suit. Notez que la valeur du secret est codée en base64, comme c'est le cas pour tout champ data d'un objet Secret.

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1

$ oc describe bc <name>

En tant que développeur, vous pouvez configurer votre compilation pour qu'elle s'exécute automatiquement chaque fois qu'une image de base est modifiée.

Vous pouvez utiliser des déclencheurs de changement d'image pour lancer automatiquement votre compilation lorsqu'une nouvelle version d'une image en amont est disponible. Par exemple, si une compilation est basée sur une image RHEL, vous pouvez déclencher l'exécution de cette compilation chaque fois que l'image RHEL change. Ainsi, l'image de l'application s'exécute toujours sur la dernière image de base RHEL.

Lors de l'utilisation d'un déclencheur de changement d'image pour le flux d'image de la stratégie, le build généré est fourni avec un tag docker immuable qui pointe vers la dernière image correspondant à ce tag. Cette nouvelle référence d'image est utilisée par la stratégie lorsqu'elle s'exécute pour la construction.

Pour les autres déclencheurs de changement d'image qui ne font pas référence au flux d'images de la stratégie, une nouvelle construction est lancée, mais la stratégie de construction n'est pas mise à jour avec une référence d'image unique.

Comme cet exemple comporte un déclencheur de changement d'image pour la stratégie, la compilation résultante est la suivante :

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

Cela garantit que la construction déclenchée utilise la nouvelle image qui vient d'être poussée dans le dépôt, et que la construction peut être relancée à tout moment avec les mêmes données.

Vous pouvez mettre en pause un déclencheur de changement d'image pour permettre plusieurs changements sur le flux d'images référencé avant qu'une compilation ne soit lancée. Vous pouvez également attribuer la valeur true à l'attribut paused lors de l'ajout initial d'un ImageChangeTrigger à un BuildConfig afin d'empêcher le déclenchement immédiat d'une compilation.

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

En plus de définir le champ image pour tous les types Strategy, pour les constructions personnalisées, la variable d'environnement OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE est vérifiée. Si elle n'existe pas, elle est créée avec la référence d'image immuable. Si elle existe, elle est mise à jour avec la référence d'image immuable.

Si une compilation est déclenchée par un webhook ou une demande manuelle, la compilation créée utilise le <immutableid> résolu à partir du ImageStream référencé par le Strategy. Cela garantit que les compilations sont effectuées en utilisant des balises d'image cohérentes pour faciliter la reproduction.

En tant que développeur, si vous avez des déclencheurs de changement d'image, vous pouvez identifier le changement d'image qui a déclenché la dernière compilation. Cela peut s'avérer utile pour le débogage ou le dépannage des constructions.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: bc-ict-example
  namespace: bc-ict-example-namespace
spec:

# ...

  triggers:
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input:latest
        namespace: bc-ict-example-namespace
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input2:latest
        namespace: bc-ict-example-namespace
    type: ImageChange
status:
  imageChangeTriggers:
  - from:
      name: input:latest
      namespace: bc-ict-example-namespace
    lastTriggerTime: "2021-06-30T13:47:53Z"
    lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69
  - from:
      name: input2:latest
      namespace: bc-ict-example-namespace
    lastTriggeredImageID:  image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69

  lastVersion: 1

Chaque site BuildTriggerPolicy possède un champ type et un ensemble de champs pointeurs. Chaque champ pointeur correspond à l'une des valeurs autorisées pour le champ type. Ainsi, vous ne pouvez attribuer à BuildTriggerPolicy qu'un seul champ de pointeurs.

Pour les déclencheurs de changement d'image, la valeur de type est ImageChange. Ensuite, le champ imageChange est le pointeur vers un objet ImageChangeTrigger, qui possède les champs suivants :

The from field has the following fields of note: kind: For image change triggers, the only supported value is ImageStreamTag. namespace: You use this field to specify the namespace of the ImageStreamTag. ** name: You use this field to specify the ImageStreamTag.

Le site ImageChangeTriggerStatus qui contient la version la plus récente de lastTriggerTime a déclenché la version la plus récente. Vous utilisez ses name et namespace pour identifier le déclencheur de changement d'image dans buildConfig.spec.triggers qui a déclenché la compilation.

Le site lastTriggerTime dont l'horodatage est le plus récent correspond au site ImageChangeTriggerStatus de la dernière version. Ce ImageChangeTriggerStatus a les mêmes name et namespace que le déclencheur de changement d'image dans buildConfig.spec.triggers qui a déclenché la construction.

Un déclencheur de changement de configuration permet de lancer automatiquement une compilation dès qu'un nouveau site BuildConfig est créé.

Voici un exemple de définition de déclencheur YAML dans la base de données BuildConfig:

  type: "ConfigChange"

$ oc set triggers --help

Il existe différentes façons de configurer le crochet de post-construction. Tous les formulaires des exemples suivants sont équivalents et s'exécutent à l'adresse bundle exec rake test --verbose.

La commande oc set build-hook peut être utilisée pour définir le crochet de compilation pour une configuration de compilation.