Chapitre 3. Pipelines

Cette mise à jour inclut les changements suivants, incompatibles avec le passé :

Si la fonctionnalité de mesure des pipelines ne fonctionne pas après une mise à niveau du cluster, exécutez la commande suivante en guise de solution de contournement :

oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets

$ oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets

Cette mise à jour corrige la réconciliation de PipelineRunStatus lors de la modification de l'indicateur de fonctionnalité EmbeddedStatus. Cette mise à jour réinitialise les paramètres suivants :

Lorsque vous exécutez le jeu de commandes tkn pac sous Windows, vous pouvez recevoir le message d'erreur suivant : Command finished with error: not supported by Windows.

Solution de contournement : Définissez la variable d'environnement NO_COLOR sur true.

L'exécution de la commande tkn pac resolve -f <filename> | oc create -f peut ne pas donner les résultats escomptés si la commande tkn pac resolve utilise une valeur de paramètre modélisée pour fonctionner.

Solution : Pour atténuer ce problème, enregistrez la sortie de tkn pac resolve dans un fichier temporaire en exécutant la commande tkn pac resolve -f <filename> -o tempfile.yaml, puis la commande oc create -f tempfile.yaml. Par exemple, tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml.

Avant cette mise à jour, si vous définissiez le paramètre timeouts.pipeline sur 0, vous ne pouviez pas définir les paramètres timeouts.tasks ou timeouts.finally. Cette mise à jour résout le problème. Désormais, lorsque vous définissez la valeur du paramètre timeouts.pipeline, vous pouvez définir la valeur du paramètre "timeouts.tasks" ou du paramètre timeouts.finally. Par exemple :

yaml
kind: PipelineRun
spec:
  timeouts:
    pipeline: "0"  # No timeout
    tasks: "0h3m0s"

yaml
kind: PipelineRun
spec:
  timeouts:
    pipeline: "0"  # No timeout
    tasks: "0h3m0s"

Avant cette mise à jour, lors de l'utilisation d'un pipeline avec un registre d'images interne à OpenShift, l'URL de l'image devait être codée en dur dans la définition du pipeline. Par exemple, l'URL de l'image devait être codée en dur dans la définition de l'exécution du pipeline :

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>'
...

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>'
...

Lors de l'utilisation d'une exécution de pipeline dans le contexte de Pipelines as Code, ces valeurs codées en dur empêchaient les définitions d'exécution de pipeline d'être utilisées dans différents clusters et espaces de noms.

Avec cette mise à jour, vous pouvez utiliser les variables de modèle dynamiques au lieu de coder en dur les valeurs des espaces de noms et des noms d'exécutions de pipeline pour généraliser les définitions d'exécutions de pipeline. Par exemple :

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)'
...

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)'
...

La valeur de CATALOG_REFRESH_INTERVAL, un champ de l'objet Hub API ConfigMap utilisé dans le Tekton Hub CR, n'est pas mise à jour avec une valeur personnalisée fournie par l'utilisateur.

Solution de contournement : Aucune. Vous pouvez suivre le problème SRVKP-2854.

Cette mise à jour modifie le niveau de métrique par défaut des ressources TaskRun et PipelineRun pour les valeurs suivantes :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-observability
  namespace: tekton-pipelines
  labels:
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
data:
  _example: |
  ...
    metrics.taskrun.level: "task"
    metrics.taskrun.duration-type: "histogram"
    metrics.pipelinerun.level: "pipeline"
    metrics.pipelinerun.duration-type: "histogram"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-observability
  namespace: tekton-pipelines
  labels:
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
data:
  _example: |
  ...
    metrics.taskrun.level: "task"
    metrics.taskrun.duration-type: "histogram"
    metrics.pipelinerun.level: "pipeline"
    metrics.pipelinerun.duration-type: "histogram"

Red Hat OpenShift Pipelines 1.7.x était livré avec Pipelines as Code 0.5.x. La mise à jour actuelle est livrée avec Pipelines as Code 0.10.x. Ce changement crée une nouvelle route dans l'espace de noms openshift-pipelines pour le nouveau contrôleur. Vous devez mettre à jour cette route dans les applications GitHub ou les webhooks qui utilisent Pipelines as Code. Pour récupérer la route, utilisez la commande suivante :

oc get route -n openshift-pipelines pipelines-as-code-controller \
  --template='https://{{ .spec.host }}'

$ oc get route -n openshift-pipelines pipelines-as-code-controller \
  --template='https://{{ .spec.host }}'

Avec cette mise à jour, Pipelines as Code met à jour les commandes suivantes dans l'outil CLI tkn-pac:

À partir d'OpenShift Container Platform 4.11, les canaux preview et stable pour l'installation et la mise à jour de Red Hat OpenShift Pipelines Operator sont supprimés. Pour installer et mettre à niveau l'opérateur, utilisez le canal pipelines-<version> approprié ou le canal latest pour la version stable la plus récente. Par exemple, pour installer la version 1.8.x d'OpenShift Pipelines Operator, utilisez le canal pipelines-1.8.

La prise en charge de la version de l'API tekton.dev/v1alpha1, qui était obsolète dans Red Hat OpenShift Pipelines GA 1.6, devrait être supprimée dans la prochaine version Red Hat OpenShift Pipelines GA 1.9.

Ce changement affecte le composant pipeline, qui comprend les ressources TaskRun, PipelineRun, Task, Pipeline, et les ressources similaires tekton.dev/v1alpha1. Comme alternative, mettez à jour les ressources existantes pour utiliser apiVersion: tekton.dev/v1beta1 comme décrit dans Migrating From Tekton v1alpha1 to Tekton v1beta1.

Les corrections de bogues et l'assistance pour la version de l'API tekton.dev/v1alpha1 ne sont fournies que jusqu'à la fin du cycle de vie actuel de l'AG 1.8.

Dans Red Hat OpenShift Pipelines 1.8, l'état pipelineRunCancelled est déprécié et il est prévu de le supprimer dans une prochaine version. La terminaison gracieuse des objets PipelineRun est maintenant promue d'une fonctionnalité alpha à une fonctionnalité stable (voir TEP-0058 : Terminaison gracieuse de l'exécution du pipeline). (Voir TEP-0058 : Graceful Pipeline Run Termination.) Comme alternative, vous pouvez utiliser l'état Cancelled, qui remplace l'état pipelineRunCancelled.

Vous n'avez pas besoin de modifier vos ressources Pipeline et Task. Si vous avez des outils qui annulent les exécutions de pipeline, vous devez les mettre à jour dans la prochaine version. Ce changement affecte également les outils tels que le CLI, les extensions de l'IDE, etc., afin qu'ils prennent en charge les nouveaux statuts PipelineRun.

Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

Dans Red Hat OpenShift Pipelines 1.8, le champ timeout dans PipelineRun a été déprécié. À la place, utilisez le champ PipelineRun.Timeouts, qui est maintenant passé d'une fonctionnalité alpha à une fonctionnalité stable.

Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

Le pipeline s2i-nodejs ne peut pas utiliser le flux d'images nodejs:14-ubi8-minimal pour effectuer des constructions source-image (S2I). L'utilisation de ce flux d'images produit un message error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127.

Solution de contournement : Utilisez nodejs:14-ubi8 plutôt que le flux d'images nodejs:14-ubi8-minimal.

Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x).

Solution de contournement : Spécifiez une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.

Avant cette mise à jour, si le <NAME> dans $params["<NAME>"] ou $params['<NAME>'] contenait un point (.), toute partie du nom à droite du point n'était pas extraite. Par exemple, à partir de $params["org.ipsum.lorem"], seul org était extrait.

Cette mise à jour corrige le problème de sorte que $params récupère la valeur complète. Par exemple, $params["org.ipsum.lorem"] et $params['org.ipsum.lorem'] sont valides et la valeur complète de <NAME>, org.ipsum.lorem, est extraite.

Il génère également une erreur si <NAME> n'est pas entouré de guillemets simples ou doubles. Par exemple, $params.org.ipsum.lorem n'est pas valide et génère une erreur de validation.

Avant cette mise à jour, l'installation de Red Hat OpenShift Pipelines Operator sur OpenShift Container Platform 4.9 et 4.10 échouait en raison d'une liaison de rôle non valide, avec le message d'erreur suivant :

error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io
"openshift-operators-prometheus-k8s-read-binding" is invalid:
roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io
"openshift-operators-prometheus-k8s-read-binding" is invalid:
roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

Cette mise à jour corrige le problème de sorte que l'échec ne se produise plus.

Auparavant, avec l'élagueur de ressources, chaque opérateur d'espace de noms créait une commande qui s'exécutait dans un conteneur distinct. Cette conception consommait trop de ressources dans les grappes comportant un grand nombre d'espaces de noms. Par exemple, pour exécuter une seule commande, une grappe de 1000 espaces de noms produisait 1000 conteneurs dans un pod.

Cette mise à jour corrige le problème. Elle transmet la configuration basée sur l'espace de noms à la tâche afin que toutes les commandes s'exécutent en boucle dans un conteneur.

Avant cette mise à jour, toutes les tâches de construction de S2I échouaient avec une erreur similaire au message suivant :

Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

Avec cette mise à jour, la contrainte de contexte de sécurité (SCC) de pipelines-scc est compatible avec la capacité de SETFCAP nécessaire pour les tâches de cluster de Buildah et S2I. Par conséquent, les tâches de construction Buildah et S2I peuvent être exécutées avec succès.

Pour exécuter avec succès la tâche de cluster Buildah et les tâches de construction S2I pour les applications écrites dans différents langages et frameworks, ajoutez l'extrait suivant pour les objets steps appropriés tels que build et push:

securityContext:
  capabilities:
    add: ["SETFCAP"]

securityContext:
  capabilities:
    add: ["SETFCAP"]

Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x). Pour contourner le problème, vous pouvez spécifier une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.

Vous ne pouvez pas utiliser le flux d'images nodejs:14-ubi8-minimal car cela génère les erreurs suivantes :

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

Cette mise à jour ajoute les types d'API v1beta1 Go. Avec cette mise à jour, les déclencheurs prennent désormais en charge la version de l'API v1beta1.

Avec la version actuelle, les fonctionnalités de v1alpha1 sont désormais obsolètes et seront supprimées dans une prochaine version. Commencez à utiliser les fonctionnalités de v1beta1 à la place.

Dans la version actuelle, l'exécution automatique des ressources est activée par défaut. En outre, vous pouvez configurer l'exécution automatique des tâches et des pipelines pour chaque espace de noms séparément, en utilisant les nouvelles annotations suivantes :

Les fonctionnalités alpha suivantes sont introduites :

La version actuelle vous permet de configurer la sélection des nœuds en spécifiant les valeurs nodeSelector et tolerations dans la ressource personnalisée (CR) TektonConfig. L'opérateur ajoute ces valeurs à tous les déploiements qu'il crée.

Dans la version 0.16.0 de Tekton Triggers, l'étiquette redondante status est supprimée des métriques de la ressource EventListener.

Avec la version actuelle, la ressource EventListener envoie une réponse avant que les déclencheurs ne terminent leur traitement.

La version actuelle supprime le champ podTemplate de la ressource EventListener.

La version actuelle supprime le champ replicas, obsolète, de la spécification de la ressource EventListener.

Dans Red Hat OpenShift Pipelines 1.6, les valeurs de HOME="/tekton/home" et workingDir="/workspace" sont supprimées de la spécification des objets Step.

Au lieu de cela, Red Hat OpenShift Pipelines définit HOME et workingDir aux valeurs définies par les conteneurs exécutant les objets Step. Vous pouvez remplacer ces valeurs dans la spécification de vos objets Step.

Pour utiliser l'ancien comportement, vous pouvez remplacer les champs disable-working-directory-overwrite et disable-home-env-overwrite de la CR TektonConfig par false:

apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    pipeline:
      disable-working-directory-overwrite: false
      disable-home-env-overwrite: false
  ...

apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    pipeline:
      disable-working-directory-overwrite: false
      disable-home-env-overwrite: false
  ...

Vous ne pouvez pas utiliser le flux d'images nodejs:14-ubi8-minimal car cela génère les erreurs suivantes :

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

Les exécutions de pipelines et de tâches seront automatiquement élaguées par une tâche cron dans l'espace de noms cible. La tâche cron utilise la variable d'environnement IMAGE_JOB_PRUNER_TKN pour obtenir la valeur de tkn image. Avec cette amélioration, les champs suivants sont introduits dans la ressource personnalisée TektonConfig:

...
pruner:
  resources:
    - pipelinerun
    - taskrun
  schedule: "*/5 * * * *" # cron schedule
  keep: 2 # delete all keeping n
...

...
pruner:
  resources:
    - pipelinerun
    - taskrun
  schedule: "*/5 * * * *" # cron schedule
  keep: 2 # delete all keeping n
...

Dans OpenShift Container Platform, vous pouvez personnaliser l'installation du composant Tekton Add-ons en modifiant les valeurs des nouveaux paramètres clusterTasks et pipelinesTemplates dans la ressource personnalisée TektonConfig:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
...

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
...

La personnalisation est possible si vous créez le module complémentaire à l'aide de TektonConfig ou directement à l'aide de Tekton Add-ons. Toutefois, si les paramètres ne sont pas transmis, le contrôleur ajoute des paramètres avec des valeurs par défaut.

Le paramètre enableMetrics est ajouté à la ressource personnalisée TektonConfig. Vous pouvez l'utiliser pour désactiver le moniteur de service, qui fait partie de Tekton Pipelines pour OpenShift Container Platform.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  pipeline:
    params:
    - name: enableMetrics
      value: "true"
...

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  pipeline:
    params:
    - name: enableMetrics
      value: "true"
...

La définition de la ressource personnalisée ClusterInterceptor pour l'enregistrement des intercepteurs a été ajoutée, ce qui vous permet d'enregistrer de nouveaux types Interceptor que vous pouvez ajouter. En outre, les modifications suivantes ont été apportées :

La commande tkn start [task | clustertask | pipeline] démarre de manière interactive et demande la valeur params, même si les paramètres par défaut sont spécifiés. Pour arrêter les invites interactives, passez le drapeau --use-param-defaults au moment de l'invocation de la commande. Par exemple :

tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \
    --use-param-defaults

$ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \
    --use-param-defaults

Dans les expressions when, la prise en charge des champs écrits en PascalCase est supprimée. Les expressions when ne prennent en charge que les champs écrits en minuscules.

Lorsque vous mettez à niveau Red Hat OpenShift Pipelines Operator vers v1.5, les tâches de cluster openshift-client et openshift-client-v-1-5-0 ont le paramètre SCRIPT. Cependant, le paramètre ARGS et la ressource git sont supprimés de la spécification de la tâche de cluster openshift-client. Il s'agit d'un changement radical, et seules les tâches de cluster qui n'ont pas de version spécifique dans le champ name de la ressource ClusterTask sont mises à niveau de manière transparente.

Pour éviter que le pipeline ne s'interrompe, utilisez le paramètre SCRIPT après la mise à niveau, car il déplace les valeurs précédemment spécifiées dans le paramètre ARGS vers le paramètre SCRIPT de la tâche de cluster. Par exemple :

...
- name: deploy
  params:
  - name: SCRIPT
    value: oc rollout status <deployment-name>
  runAfter:
    - build
  taskRef:
    kind: ClusterTask
    name: openshift-client
...

...
- name: deploy
  params:
  - name: SCRIPT
    value: oc rollout status <deployment-name>
  runAfter:
    - build
  taskRef:
    kind: ClusterTask
    name: openshift-client
...

Lorsque vous mettez à niveau Red Hat OpenShift Pipelines Operator v1.4 vers v1.5, les noms de profil dans lesquels la ressource personnalisée TektonConfig est installée changent désormais.

Les champs disable-home-env-overwrite et disable-working-dir-overwrite sont désormais obsolètes et seront supprimés dans une prochaine version. Pour cette version, la valeur par défaut de ces drapeaux est fixée à true pour des raisons de compatibilité ascendante.

Le statut de la ressource EventListener est assorti d'une nouvelle condition appelée Ready.

Le champ replicas est obsolète dans la spécification EventListener. Le champ spec.replicas est déplacé vers spec.resources.kubernetesResource.replicas dans la spécification KubernetesResource.

La tâche cluster git-cli est construite à partir de l'image de base alpine/git, qui attend /root comme répertoire personnel de l'utilisateur. Cependant, cela n'est pas explicitement défini dans la tâche de cluster git-cli.

Dans Tekton, le répertoire d'accueil par défaut est remplacé par /tekton/home à chaque étape d'une tâche, sauf indication contraire. Cet écrasement de la variable d'environnement $HOME de l'image de base entraîne l'échec de la tâche de cluster git-cli.

Ce problème devrait être corrigé dans les prochaines versions. Pour Red Hat OpenShift Pipelines 1.5 et les versions antérieures, vous pouvez use any one of the following workarounds pour éviter l'échec de la tâche de cluster git-cli:

Les tâches personnalisées présentent les améliorations suivantes :

La tâche finally présente les améliorations suivantes :

La contrainte de contexte de sécurité (SCC) pipelines-scc est utilisée avec le compte de service par défaut pipeline pour les pipelines. Ce nouveau compte de service est similaire à anyuid, mais avec une différence mineure telle que définie dans le YAML pour SCC de OpenShift Container Platform 4.7 :

fsGroup:
  type: MustRunAs

fsGroup:
  type: MustRunAs

Dans la spécification et la liaison des déclencheurs, le champ obsolète template.name est supprimé au profit de template.ref. Vous devez mettre à jour toutes les définitions de eventListener pour utiliser le champ ref.

Les déclencheurs génèrent une erreur résultant d'une mauvaise gestion du format JSON, si vous avez la configuration suivante dans la liaison du déclencheur :

params:
  - name: github_json
    value: $(body)

params:
  - name: github_json
    value: $(body)

Pour résoudre le problème :

La désinstallation de Red Hat OpenShift Pipelines Operator ne supprime pas les écouteurs d'événements.

En guise de solution de contournement, supprimer les CRD EventListener et Pod:

Lorsque vous exécutez une tâche d'image de conteneur multiarchitecture sans spécification de commande sur un cluster IBM Power Systems (ppc64le) ou IBM Z (s390x), la ressource TaskRun échoue avec l'erreur suivante :

Error executing command: fork/exec /bin/bash: exec format error

Error executing command: fork/exec /bin/bash: exec format error

Comme solution de contournement, utilisez une image de conteneur spécifique à l'architecture ou spécifiez le résumé sha256 pour qu'il pointe vers l'architecture correcte. Pour obtenir le condensé sha256, entrez :

skopeo inspect --raw <image_name>| jq '.manifests[] | select(.platform.architecture == "<architecture>") | .digest'

$ skopeo inspect --raw <image_name>| jq '.manifests[] | select(.platform.architecture == "<architecture>") | .digest'

La variable d'environnement $HOME et la variable workingDir dans la spécification Steps sont obsolètes et pourraient être modifiées dans une version ultérieure. Actuellement, dans un conteneur Step, les variables HOME et workingDir sont remplacées par les variables /tekton/home et /workspace, respectivement.

Dans une version ultérieure, ces deux champs ne seront pas modifiés et prendront les valeurs définies dans l'image du conteneur et dans le YAML Task. Pour cette version, utilisez les drapeaux disable-home-env-overwrite et disable-working-directory-overwrite pour désactiver l'écrasement des variables HOME et workingDir.

La tâche buildah cluster ne fonctionne pas lorsqu'un nouvel utilisateur est ajouté à un conteneur.

Lors de l'installation de l'Opérateur, l'indicateur --storage-driver pour la tâche de cluster buildah n'est pas spécifié, et l'indicateur prend donc sa valeur par défaut. Dans certains cas, cela entraîne un mauvais paramétrage du pilote de stockage. Lorsqu'un nouvel utilisateur est ajouté, le pilote de stockage incorrect entraîne l'échec de la tâche de cluster buildah avec l'erreur suivante :

useradd: /etc/passwd.8: lock file already used
useradd: cannot lock /etc/passwd; try again later.

useradd: /etc/passwd.8: lock file already used
useradd: cannot lock /etc/passwd; try again later.

Pour contourner le problème, définissez manuellement la valeur de l'indicateur --storage-driver à overlay dans le fichier buildah-task.yaml:

Vous pouvez également modifier le fichier YAML de la tâche de cluster buildah directement sur la console web en naviguant vers Pipelines Cluster Tasks buildah. Sélectionnez Edit Cluster Task dans le menu Actions et remplacez le champ command comme indiqué dans la procédure précédente.