• fichier .gitconfig
• Authentification de base
• Authentification par clé SSH
• Autorités de certification de confiance

• Créer un objet secret avec des données secrètes.
• Mettre à jour le compte de service pod pour autoriser la référence au secret.
• Créer un pod, qui consomme le secret en tant que variable d'environnement ou en tant que fichier à l'aide d'un volume secret.

Procédure

• La commande create permet de créer un objet secret à partir d'un fichier JSON ou YAML :

  $ oc create -f <filename>

  Par exemple, vous pouvez créer un secret à partir de votre fichier local .docker/config.json:

  $ oc create secret generic dockerhub \
      --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
      --type=kubernetes.io/dockerconfigjson

  Cette commande génère une spécification JSON du secret nommé dockerhub et crée l'objet.

  Définition de l'objet secret opaque YAML

  apiVersion: v1
  kind: Secret
  metadata:
    name: mysecret
  type: Opaque 1
  data:
    username: dXNlci1uYW1l
    password: cGFzc3dvcmQ=

  1

  Spécifie un secret opaque.

  Fichier JSON de configuration Docker Définition de l'objet secret

  apiVersion: v1
  kind: Secret
  metadata:
    name: aregistrykey
    namespace: myapps
  type: kubernetes.io/dockerconfigjson 1
  data:
    .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

  1

  Spécifie que le secret utilise un fichier JSON de configuration de docker.

  2

  La sortie d'un fichier JSON de configuration de docker encodé en base64

Procédure

• Définissez la source de la variable d'environnement fieldPath à l'adresse JsonPath du champ dont vous souhaitez obtenir la valeur :

  env:
    - name: FIELDREF_ENV
      valueFrom:
        fieldRef:
          fieldPath: metadata.name

Procédure

• Pour utiliser un secret comme variable d'environnement, définissez la syntaxe valueFrom:

  apiVersion: build.openshift.io/v1
  kind: BuildConfig
  metadata:
    name: secret-example-bc
  spec:
    strategy:
      sourceStrategy:
        env:
        - name: MYVAL
          valueFrom:
            secretKeyRef:
              key: myval
              name: mysecret

Procédure

• Réglez le site imageOptimizationPolicy sur SkipLayers:

  strategy:
    dockerStrategy:
      imageOptimizationPolicy: SkipLayers

Conditions préalables

• Vous avez ajouté un secret d'entrée, une carte de configuration ou les deux à un objet BuildConfig.

Procédure

• Dans la définition dockerStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

  spec:
    dockerStrategy:
      volumes:
        - name: secret-mvn 1
          mounts:
          - destinationPath: /opt/app-root/src/.ssh 2
          source:
            type: Secret 3
            secret:
              secretName: my-secret 4
        - name: settings-mvn 5
          mounts:
          - destinationPath: /opt/app-root/src/.m2  6
          source:
            type: ConfigMap 7
            configMap:
              name: my-config 8
        - name: my-csi-volume 9
          mounts:
          - destinationPath: /opt/app-root/src/some_path  10
          source:
            type: CSI 11
            csi:
              driver: csi.sharedresource.openshift.io 12
              readOnly: true 13
              volumeAttributes: 14
                attribute: value

  1 5 9

  Obligatoire. Un nom unique.

  2 6 10

  Obligatoire. Le chemin absolu du point de montage. Il ne doit pas contenir .. ou : et ne doit pas entrer en conflit avec le chemin de destination généré par le constructeur. /opt/app-root/src est le répertoire d'accueil par défaut pour de nombreuses images Red Hat S2I.

  3 7 11

  Obligatoire. Le type de source, ConfigMap, Secret, ou CSI.

  4 8

  Obligatoire. Le nom de la source.

  12

  Nécessaire. Le pilote qui fournit le volume CSI éphémère.

  13

  Obligatoire. Cette valeur doit être définie sur true. Fournit un volume en lecture seule.

  14

  Facultatif. Les attributs de volume du volume CSI éphémère. Consultez la documentation du pilote CSI pour connaître les clés et les valeurs des attributs pris en charge.

Procédure

• Pour créer une construction incrémentielle, créez une stratégie avec la modification suivante de la définition de la stratégie :

  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "incremental-image:latest" 1
      incremental: true 2

  1

  Spécifiez une image qui prend en charge les constructions incrémentielles. Consultez la documentation de l'image du constructeur pour savoir si elle prend en charge ce comportement.

  2

  Cette option permet de contrôler si une construction incrémentale est tentée. Si l'image du constructeur ne prend pas en charge les constructions incrémentielles, la construction réussira quand même, mais vous obtiendrez un message indiquant que la construction incrémentielle n'a pas réussi à cause d'un script save-artifacts manquant.

• Fournissez un script assemble, run ou save-artifacts dans le répertoire .s2i/bin du référentiel des sources de votre application.

• Fournir l'URL d'un répertoire contenant les scripts dans le cadre de la définition de la stratégie. Par exemple :

  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "builder-image:latest"
      scripts: "http://somehost.com/scripts_directory" 1

  1

  Ce chemin sera complété par run, assemble, et save-artifacts. Si l'un ou tous les scripts sont trouvés, ils seront utilisés à la place des scripts du même nom fournis dans l'image.

Conditions préalables

• Vous avez ajouté un secret d'entrée, une carte de configuration ou les deux à un objet BuildConfig.

Procédure

• Dans la définition sourceStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

  spec:
    sourceStrategy:
      volumes:
        - name: secret-mvn 1
          mounts:
          - destinationPath: /opt/app-root/src/.ssh 2
          source:
            type: Secret 3
            secret:
              secretName: my-secret 4
        - name: settings-mvn 5
          mounts:
          - destinationPath: /opt/app-root/src/.m2 6
          source:
            type: ConfigMap 7
            configMap:
              name: my-config 8
        - name: my-csi-volume 9
          mounts:
          - destinationPath: /opt/app-root/src/some_path  10
          source:
            type: CSI 11
            csi:
              driver: csi.sharedresource.openshift.io 12
              readOnly: true 13
              volumeAttributes: 14
                attribute: value

Procédure

• Définir la section customStrategy.from:

  strategy:
    customStrategy:
      from:
        kind: "DockerImage"
        name: "openshift/sti-image-builder"

Procédure

• Pour monter chaque secret à un emplacement spécifique, modifiez les champs secretSource et mountPath du fichier YAML strategy:

  strategy:
    customStrategy:
      secrets:
        - secretSource: 1
            name: "secret1"
          mountPath: "/tmp/secret1" 2
        - secretSource:
            name: "secret2"
          mountPath: "/tmp/secret2"

  1

  secretSource est une référence à un secret dans le même espace de noms que la construction.

  2

  mountPath est le chemin d'accès à l'intérieur du constructeur personnalisé où le secret doit être monté.

• Création dynamique de tâches et d'exécutions dans Jenkins.
• Création dynamique de modèles de pods d'agents à partir de flux d'images, de balises de flux d'images ou de cartes de configuration.
• Injection de variables d'environnement.
• Visualisation du pipeline dans la console web de OpenShift Container Platform.
• Intégration avec le plugin Jenkins Git, qui transmet les informations de commit des builds d'OpenShift Container Platform au plugin Jenkins Git.
• Synchronisation des secrets dans les entrées de justificatifs Jenkins.

• Un champ en ligne jenkinsfile dans votre configuration de construction.
• Un champ jenkinsfilePath dans votre configuration de construction qui référence l'emplacement de jenkinsfile à utiliser par rapport à la source contextDir.

• Un fichier situé dans votre dépôt de code source.
• Intégrée dans votre configuration de construction à l'aide du champ jenkinsfile.

• Un fichier nommé jenkinsfile à la racine de votre référentiel.
• Un fichier nommé jenkinsfile à la racine de la source contextDir de votre référentiel.
• Un nom de fichier spécifié via le champ jenkinsfilePath de la section JenkinsPipelineStrategy de votre BuildConfig, qui est relatif à la source contextDir si elle est fournie, sinon il prend par défaut la racine du référentiel.

• Intégrer le fichier Jenkins dans la configuration de construction.
• Inclure dans la configuration de construction une référence au dépôt Git qui contient le fichier Jenkins.

Procédure

• Pour définir les variables d'environnement à utiliser lors de la construction, éditez le fichier YAML :

  jenkinsPipelineStrategy:
  ...
    env:
      - name: "FOO"
        value: "BAR"

Procédure

• Pour réexécuter manuellement une compilation, entrez la commande suivante :

  oc start-build --from-build=<nom_de_la_construction>

Procédure

• Pour diffuser manuellement les journaux d'une compilation dans stdout, entrez la commande suivante :

  oc start-build <buildconfig_name> --follow

Procédure

• Pour spécifier une variable d'environnement souhaitée, entrez la commande suivante :

  $ oc start-build <buildconfig_name> --env=<key>=<value>

Procédure

• Lancez une compilation à partir d'une source en utilisant la commande suivante pour envoyer le contenu d'un dépôt Git local sous forme d'archive à partir de la balise v2:

  $ oc start-build hello-world --from-repo=../hello-world --commit=v2

Procédure

• Pour annuler manuellement plusieurs constructions, entrez la commande suivante :

  oc cancel-build <build1_name> <build2_name> <build3_name> $ oc cancel-build <build1_name> <build2_name>

Procédure

• Pour annuler toutes les constructions, entrez la commande suivante :

  oc cancel-build bc/<buildconfig_name>

Procédure

• Pour annuler tout ce qui se trouve dans un état donné, entrez la commande suivante :

  oc cancel-build bc/<buildconfig_name>

Procédure

• Pour diffuser les journaux de la dernière version pour une BuildConfig, entrez la commande suivante :

  oc logs -f bc/<buildconfig_name>

Procédure

• Pour diffuser les journaux d'une version donnée pour une BuildConfig, entrez la commande suivante :

  oc logs --version=<number> bc/<buildconfig_name>

Procédure

• Pour obtenir une sortie plus verbeuse, transmettez la variable d'environnement BUILD_LOGLEVEL à l'adresse sourceStrategy ou dockerStrategy à l'adresse BuildConfig:

  sourceStrategy:
  ...
    env:
      - name: "BUILD_LOGLEVEL"
        value: "2" 1

  1

  Ajustez cette valeur au niveau d'enregistrement souhaité.

Conditions préalables

• Vous avez configuré plusieurs déclencheurs de changement d'image. Ces déclencheurs ont déclenché une ou plusieurs constructions.

• lastTriggeredImageID: Ce champ, qui n'apparaît pas dans l'exemple, est obsolète dans OpenShift Container Platform 4.8 et sera ignoré dans une prochaine version. Il contient la référence de l'image résolue pour le ImageStreamTag lorsque le dernier build a été déclenché à partir de ce BuildConfig.
• paused: Vous pouvez utiliser ce champ, qui n'apparaît pas dans l'exemple, pour désactiver temporairement ce déclencheur de changement d'image particulier.
• from: Ce champ permet de référencer le site ImageStreamTag qui pilote ce déclencheur de changement d'image. Son type est le type de base de Kubernetes, OwnerReference.

Procédure

• Script shell :

  postCommit:
    script: "bundle exec rake test --verbose"

  La valeur script est un script shell à exécuter avec /bin/sh -ic. Utilisez cette valeur lorsqu'un script shell est approprié pour exécuter le crochet de compilation. Par exemple, pour exécuter des tests unitaires comme ci-dessus. Pour contrôler le point d'entrée de l'image, ou si l'image n'a pas /bin/sh, utilisez command et/ou args.

  Note

  Le drapeau supplémentaire -i a été introduit pour améliorer l'expérience de travail avec les images CentOS et RHEL, et pourrait être supprimé dans une prochaine version.

• Comme point d'entrée de l'image :

  postCommit:
    command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]

  Dans cette forme, command est la commande à exécuter, qui remplace le point d'entrée de l'image dans la forme exec, comme documenté dans la référence Dockerfile. Ceci est nécessaire si l'image n'a pas /bin/sh, ou si vous ne voulez pas utiliser un shell. Dans tous les autres cas, l'utilisation de script peut être plus pratique.

• Commande avec arguments :

  postCommit:
    command: ["bundle", "exec", "rake", "test"]
    args: ["--verbose"]

  Cette forme est équivalente à l'ajout des arguments à command.

Conditions préalables

• Vous devez fournir ou créer un fichier de configuration du dépôt compatible avec yum qui télécharge le contenu de votre instance Satellite.

  Exemple de configuration du référentiel

  [test-<name>]
  name=test-<number>
  baseurl = https://satellite.../content/dist/rhel/server/7/7Server/x86_64/os
  enabled=1
  gpgcheck=0
  sslverify=0
  sslclientkey = /etc/pki/entitlement/...-key.pem
  sslclientcert = /etc/pki/entitlement/....pem

Conditions préalables

• Vous avez ajouté les clés d'habilitation et les configurations du référentiel satellite en tant que volumes de construction.

• Avec cette mise à jour, la version précédente de la commande tkn n'est pas compatible avec Red Hat OpenShift Pipelines 1.10.
• Cette mise à jour supprime la prise en charge des ressources de pipeline Cluster et CloudEvent dans Tekton CLI. Vous ne pouvez pas créer de ressources de pipeline en utilisant la commande tkn pipelineresource create. De plus, les ressources de pipeline ne sont plus prises en charge dans la commande start d'une tâche, d'une tâche de cluster ou d'un pipeline.
• Cette mise à jour supprime tekton en tant que format de provenance des chaînes Tekton.

• Dans Red Hat OpenShift Pipelines 1.10, les commandes ClusterTask sont désormais obsolètes et devraient être supprimées dans une prochaine version. La commande tkn task create est également obsolète avec cette mise à jour.
• Dans Red Hat OpenShift Pipelines 1.10, les drapeaux -i et -o qui étaient utilisés avec la commande tkn task start sont désormais obsolètes car l'API v1 ne prend pas en charge les ressources de pipeline.
• Dans Red Hat OpenShift Pipelines 1.10, l'indicateur -r qui était utilisé avec la commande tkn pipeline start est obsolète car l'API v1 ne prend pas en charge les ressources de pipeline.
• La mise à jour Red Hat OpenShift Pipelines 1.10 définit le paramètre openshiftDefaultEmbeddedStatus à both avec full et minimal statut intégré. Le drapeau permettant de modifier le statut intégré par défaut est également obsolète et sera supprimé. De plus, le statut intégré par défaut du pipeline sera modifié en minimal dans une prochaine version.

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

  • Suppression de la grappe PipelineResources
  • Suppression du nuage PipelineResources

• 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

• Avec cette mise à jour, l'utilisation de bases de données externes, telles que Crunchy PostgreSQL, n'est pas prise en charge sur IBM Power, IBM zSystems et IBM® LinuxONE. Utilisez plutôt la base de données par défaut du Tekton Hub.

• Avant cette mise à jour, la commande opc pac générait une erreur d'exécution au lieu d'afficher un message d'aide. Cette mise à jour corrige la commande opc pac pour qu'elle affiche le message d'aide.
• Avant cette mise à jour, l'exécution de la commande tkn pac create repo nécessitait les détails du webhook pour créer un dépôt. Avec cette mise à jour, la commande tkn-pac create repo ne configure pas de webhook lorsque votre application GitHub est installée.
• Avant cette mise à jour, Pipelines as Code ne signalait pas d'erreur de création d'une exécution de pipeline lorsque Tekton Pipelines rencontrait des problèmes lors de la création de la ressource PipelineRun. Par exemple, une tâche inexistante dans un pipeline n'affichait aucun statut. Avec cette mise à jour, Pipelines as Code affiche le message d'erreur approprié provenant de Tekton Pipelines ainsi que la tâche manquante.
• Cette mise à jour corrige la redirection de la page de l'interface utilisateur après une authentification réussie. Désormais, vous êtes redirigé vers la même page que celle où vous avez tenté de vous connecter au Tekton Hub.
• Cette mise à jour corrige la commande list avec ces drapeaux, --all-namespaces et --output=yaml, pour une tâche en grappe, une tâche individuelle et un pipeline.
• Cette mise à jour supprime la barre oblique à la fin de l'URL de repo.spec.url afin qu'elle corresponde à l'URL provenant de GitHub.
• Avant cette mise à jour, la fonction marshalJSON n'affichait pas de liste d'objets. Avec cette mise à jour, la fonction marshalJSON gère la liste d'objets.
• Avec cette mise à jour, Pipelines as Code vous permet de contourner les questions d'entreprise de GitHub dans l'application CLI bootstrap GitHub.
• Cette mise à jour corrige la vérification des collaborateurs GitHub lorsque votre dépôt a plus de 100 utilisateurs.
• Avec cette mise à jour, les commandes sign et verify pour une tâche ou un pipeline fonctionnent désormais sans fichier de configuration kubernetes.
• Avec cette mise à jour, Tekton Operator nettoie les tâches cron d'élagage restantes si l'élagage a été ignoré sur un espace de noms.
• Avant cette mise à jour, l'objet API ConfigMap n'était pas mis à jour avec une valeur configurée par l'utilisateur pour l'intervalle de rafraîchissement du catalogue. Cette mise à jour corrige l'API CATALOG_REFRESH_INTERVAL dans le Tekon Hub CR.

• 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 :

  • Les paramètres status.runs et status.taskruns à nil avec minimal EmbeddedStatus
  • Le paramètre status.childReferences à nil avec full EmbeddedStatus
• Cette mise à jour ajoute une configuration de conversion au CRD ResolutionRequest. Cette mise à jour configure correctement la conversion de la requête v1alpha1.ResolutionRequest vers la requête v1beta1.ResolutionRequest.
• Cette mise à jour vérifie la présence d'espaces de travail en double associés à une tâche de pipeline.
• Cette mise à jour corrige la valeur par défaut de l'activation des résolveurs dans le code.
• Cette mise à jour corrige la conversion des noms TaskRef et PipelineRef à l'aide d'un résolveur.

• Avec cette mise à jour, le type de définition de ressource personnalisée (CRD) Conditions a été supprimé. Il est possible d'utiliser le type WhenExpressions à la place.
• Avec cette mise à jour, la prise en charge des ressources de pipeline de l'API tekton.dev/v1alpha1, telles que Pipeline, PipelineRun, Task, Clustertask et TaskRun, a été supprimée.
• Avec cette mise à jour, la commande tkn-pac setup a été supprimée. A la place, utilisez la commande tkn-pac webhook add pour ajouter un webhook à un référentiel Git existant. Et utilisez la commande tkn-pac webhook update-token pour mettre à jour le jeton d'accès du fournisseur personnel pour un objet Secret existant dans le référentiel Git.
• Avec cette mise à jour, un espace de noms qui exécute un pipeline avec les paramètres par défaut n'applique pas le label pod-security.kubernetes.io/enforce:privileged à une charge de travail.

• Dans la version 1.9.0 de Red Hat OpenShift Pipelines, ClusterTasks est déprécié et il est prévu de le supprimer dans une prochaine version. Comme alternative, vous pouvez utiliser Cluster Resolver.
• Dans la version 1.9.0 de Red Hat OpenShift Pipelines, l'utilisation des champs triggers et namespaceSelector dans une seule spécification EventListener est dépréciée et il est prévu de la supprimer dans une prochaine version. Vous pouvez utiliser ces champs dans différentes spécifications EventListener avec succès.
• Dans la version 1.9.0 de Red Hat OpenShift Pipelines, la commande tkn pipelinerun describe n'affiche pas les délais d'attente pour la ressource PipelineRun.
• Dans la version 1.9.0 de Red Hat OpenShift Pipelines, la ressource personnalisée (CR) PipelineResource` est obsolète. La CR PipelineResource était une fonctionnalité Tech Preview et faisait partie de l'API tekton.dev/v1alpha1.
• Dans la version 1.9.0 de Red Hat OpenShift Pipelines, les paramètres d'image personnalisée des tâches de cluster sont obsolètes. Comme alternative, vous pouvez copier une tâche de cluster et utiliser votre image personnalisée dans celle-ci.

• Les cartes de configuration chains-secret et chains-config sont supprimées après la désinstallation de Red Hat OpenShift Pipelines Operator. Comme elles contiennent des données d'utilisateur, elles doivent être conservées et non supprimées.

• 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, après avoir remplacé un tableau vide, le tableau original renvoyait une chaîne vide, ce qui rendait les paramètres qu'il contenait invalides. Avec cette mise à jour, ce problème est résolu et le tableau original retourne une chaîne vide.
• Avant cette mise à jour, si des secrets en double étaient présents dans un compte de service pour une exécution de pipeline, cela entraînait un échec dans la création du module de tâches. Avec cette mise à jour, ce problème est résolu et le module de tâches est créé avec succès même si des secrets en double sont présents dans un compte de service.
• Avant cette mise à jour, en consultant le champ spec.StatusMessage du TaskRun, les utilisateurs ne pouvaient pas savoir si le TaskRun avait été annulé par l'utilisateur ou par un PipelineRun qui en faisait partie. Avec cette mise à jour, ce problème est résolu et les utilisateurs peuvent distinguer le statut de TaskRun en regardant le champ spec.StatusMessage de la TaskRun.
• Avant cette mise à jour, la validation du webhook était supprimée lors de la suppression d'anciennes versions d'objets invalides. Avec cette mise à jour, ce problème est résolu.

• 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"

• Avant cette mise à jour, une condition de course pouvait se produire si un autre outil mettait à jour des étiquettes ou des annotations sur un PipelineRun ou un TaskRun. Avec cette mise à jour, ce problème est résolu et vous pouvez fusionner les étiquettes ou les annotations.

• Avant cette mise à jour, les clés de journal n'avaient pas les mêmes clés que dans les contrôleurs de pipeline. Avec cette mise à jour, ce problème a été résolu et les clés des journaux ont été mises à jour pour correspondre au flux de journaux des contrôleurs de pipeline. Les clés des journaux sont passées de "ts" à "timestamp", de "level" à "severity" et de "message" à "msg".

• Avant cette mise à jour, si un PipelineRun était supprimé avec un statut inconnu, un message d'erreur n'était pas généré. Avec cette mise à jour, ce problème est résolu et un message d'erreur est généré.
• Avant cette mise à jour, il était nécessaire d'utiliser le fichier kubeconfig pour accéder aux commandes de l'offre groupée telles que list et push. Avec cette mise à jour, ce problème a été résolu et le fichier kubeconfig n'est plus nécessaire pour accéder aux commandes de l'offre groupée.
• Avant cette mise à jour, si le PipelineRun parent était en cours d'exécution pendant la suppression des TaskRuns, les TaskRuns étaient supprimées. Avec cette mise à jour, ce problème est résolu et les TaskRuns ne sont pas supprimées si le PipelineRun parent est en cours d'exécution.
• Avant cette mise à jour, si l'utilisateur tentait de construire une grappe avec plus d'objets que le contrôleur de pipeline ne le permettait, l'interface de programmation Tekton n'affichait pas de message d'erreur. Avec cette mise à jour, ce problème est résolu et la CLI Tekton affiche un message d'erreur si l'utilisateur tente de construire une grappe avec plus d'objets que la limite autorisée dans le contrôleur de pipeline.

• Avant cette mise à jour, si des espaces de noms étaient supprimés du cluster, l'opérateur ne supprimait pas les espaces de noms des sujets ClusterInterceptor ClusterRoleBinding. Avec cette mise à jour, ce problème a été résolu et l'opérateur supprime les espaces de noms des sujets ClusterInterceptor ClusterRoleBinding.
• Avant cette mise à jour, l'installation par défaut de Red Hat OpenShift Pipelines Operator avait pour résultat que la ressource de liaison de rôle pipelines-scc-rolebinding security context constraint (SCC) restait dans le cluster. Avec cette mise à jour, l'installation par défaut de Red Hat OpenShift Pipelines Operator entraîne la suppression de la ressource de liaison de rôle pipelines-scc-rolebinding security context constraint (SCC) du cluster.

• Avant cette mise à jour, Pipelines as Code ne recevait pas les valeurs mises à jour de l'objet Pipelines as Code ConfigMap. Avec cette mise à jour, ce problème est résolu et l'objet Pipelines as Code ConfigMap recherche toute nouvelle modification.
• Avant cette mise à jour, le contrôleur de Pipelines as Code n'attendait pas que l'étiquette tekton.dev/pipeline soit mise à jour et ajoutait l'étiquette checkrun id, ce qui provoquait des conditions de concurrence. Avec cette mise à jour, le contrôleur de Pipelines as Code attend que l'étiquette tekton.dev/pipeline soit mise à jour et ajoute ensuite l'étiquette checkrun id, ce qui permet d'éviter les problèmes de concurrence.
• Avant cette mise à jour, la commande tkn-pac create repo ne remplaçait pas une commande PipelineRun si elle existait déjà dans le dépôt git. Avec cette mise à jour, la commande tkn-pac create est corrigée pour remplacer une commande PipelineRun si elle existe dans le dépôt git, ce qui résout le problème avec succès.
• Avant cette mise à jour, la commande tkn pac describe n'affichait pas les raisons de chaque message. Avec cette mise à jour, ce problème est corrigé et la commande tkn pac describe affiche les motifs pour chaque message.
• Avant cette mise à jour, une demande d'extraction échouait si l'utilisateur dans l'annotation fournissait des valeurs en utilisant une forme de regex, par exemple, refs/head/rel-*. La demande d'extraction échouait parce qu'il manquait refs/heads dans sa branche de base. Avec cette mise à jour, le préfixe est ajouté et on vérifie qu'il correspond. Cela résout le problème et la demande d'extraction est acceptée.

• Avant cette mise à jour, la commande tkn pac repo list ne fonctionnait pas sous Microsoft Windows. Cette mise à jour corrige le problème et vous pouvez désormais exécuter la commande tkn pac repo list sous Microsoft Windows.
• Avant cette mise à jour, l'observateur de Pipelines as Code ne recevait pas tous les événements de changement de configuration. Avec cette mise à jour, l'observateur de Pipelines as Code a été mis à jour, et maintenant l'observateur de Pipelines as Code ne manque pas les événements de changement de configuration.
• Avant cette mise à jour, les pods créés par Pipelines as Code, tels que TaskRuns ou PipelineRuns ne pouvaient pas accéder aux certificats personnalisés exposés par l'utilisateur dans le cluster. Cette mise à jour corrige le problème et vous pouvez maintenant accéder aux certificats personnalisés à partir des pods TaskRuns ou PipelineRuns dans le cluster.
• Avant cette mise à jour, sur un cluster activé avec FIPS, l'intercepteur tekton-triggers-core-interceptors core utilisé dans la ressource Trigger ne fonctionnait pas après que l'opérateur Pipelines ait été mis à niveau vers la version 1.9. Cette mise à jour résout le problème. Désormais, OpenShift utilise MInTLS 1.2 pour tous ses composants. Par conséquent, l'intercepteur central tekton-triggers-core-interceptors est mis à jour vers la version 1.2 de TLS et sa fonctionnalité fonctionne correctement.

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

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

• Avant cette mise à jour, Pipelines as Code utilisait le même jeton GitHub pour récupérer une tâche distante disponible dans le même hôte uniquement sur la branche GitHub par défaut. Cette mise à jour résout le problème. Désormais, Pipelines as Code utilise le même jeton GitHub pour récupérer une tâche distante à partir de n'importe quelle branche GitHub.

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

• Avec cette mise à jour, un problème de mauvaise configuration de l'OLM a été introduit, ce qui empêche la mise à niveau de la plateforme OpenShift Container. Ce problème sera corrigé dans une prochaine version.

• Avant cette mise à jour, un problème de mauvaise configuration OLM avait été introduit dans la version précédente, ce qui empêchait la mise à niveau d'OpenShift Container Platform. Avec cette mise à jour, ce problème de mauvaise configuration a été corrigé.

• 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"

• Avec cette mise à jour, si une annotation ou un label est présent à la fois dans les ressources Pipeline et PipelineRun, la valeur du type Run est prioritaire. Il en va de même si une annotation ou un label est présent dans les ressources Task et TaskRun.
• Dans Red Hat OpenShift Pipelines 1.8, le champ PipelineRun.Spec.ServiceAccountNames, précédemment déprécié, a été supprimé. Utilisez le champ PipelineRun.Spec.TaskRunSpecs à la place.
• Dans Red Hat OpenShift Pipelines 1.8, le champ TaskRun.Status.ResourceResults.ResourceRef, précédemment déprécié, a été supprimé. Utilisez le champ TaskRun.Status.ResourceResults.ResourceName à la place.
• Dans Red Hat OpenShift Pipelines 1.8, le type de ressource Conditions, précédemment déprécié, a été supprimé. Supprimez la ressource Conditions des définitions de ressources Pipeline qui l'incluent. Utilisez les expressions when dans les définitions PipelineRun à la place.

• Pour les chaînes Tekton, le format tekton-provenance a été supprimé dans cette version. Utilisez plutôt le format in-toto en définissant "artifacts.taskrun.format": "in-toto" dans la ressource personnalisée TektonChain.

• 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 }}'

• Avec cette mise à jour, Pipelines as Code renomme les clés secrètes par défaut pour la définition de ressource personnalisée (CRD) Repository. Dans votre CRD, remplacez token par provider.token, et remplacez secret par webhook.secret.
• Avec cette mise à jour, Pipelines as Code remplace une variable de modèle spéciale par une variable qui prend en charge des exécutions de pipeline multiples pour des dépôts privés. Dans vos exécutions du pipeline, remplacez secret: pac-git-basic-auth-{{repo_owner}}-{{repo_name}} par secret: {{ git_auth_secret }}.

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

  • Remplacer tkn pac repository create par tkn pac create repository.
  • Remplacer tkn pac repository delete par tkn pac delete repository.
  • Remplacer tkn pac repository list par tkn pac list.

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

  Note

  Dans OpenShift Container Platform 4.10 et les versions antérieures, vous pouvez utiliser les canaux preview et stable pour installer et mettre à niveau l'opérateur.

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

  Important

  Pour Tekton Operator, la version de l'API operator.tekton.dev/v1alpha1 est not deprecated. Il n'est pas nécessaire de modifier cette valeur.

• Dans Red Hat OpenShift Pipelines 1.8, la ressource personnalisée (CR) PipelineResource est disponible mais n'est plus prise en charge. La CR PipelineResource était une fonctionnalité Tech Preview et faisait partie de l'API tekton.dev/v1alpha1, qui a été dépréciée et qu'il est prévu de supprimer dans la prochaine version Red Hat OpenShift Pipelines GA 1.9.
• Dans Red Hat OpenShift Pipelines 1.8, la ressource personnalisée (CR) Condition est supprimée. La CR Condition faisait partie de l'API tekton.dev/v1alpha1, qui a été dépréciée et devrait être supprimée dans la prochaine version de Red Hat OpenShift Pipelines GA 1.9.
• Dans Red Hat OpenShift Pipelines 1.8, l'image gcr.io pour gsutil a été supprimée. Cette suppression pourrait interrompre les clusters avec les ressources Pipeline qui dépendent de cette image. Les corrections de bugs et l'assistance sont fournies uniquement jusqu'à la fin du cycle de vie de Red Hat OpenShift Pipelines 1.7.

• Dans Red Hat OpenShift Pipelines 1.8, les champs PipelineRun.Status.TaskRuns et PipelineRun.Status.Runs sont dépréciés et devraient être supprimés dans une prochaine version. Voir TEP-0100 : Embedded TaskRuns and Runs Status in PipelineRuns.

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

• Dans Red Hat OpenShift Pipelines 1.8, les conteneurs init sont omis des calculs de demande par défaut de l'objet LimitRange.

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

  Astuce

  Avant d'installer des tâches basées sur le catalogue Tekton sur ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) en utilisant tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont répertoriés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>

• Sur ARM, IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.

• Le mappage implicite des paramètres transmet incorrectement les paramètres des définitions de premier niveau Pipeline ou PipelineRun aux tâches taskRef. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en ligne taskSpec. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champ enable-api-fields sur alpha dans la section pipeline de la définition de la ressource personnalisée TektonConfig.

• Avant cette mise à jour, les métriques pour les exécutions de pipeline dans la vue Développeur de la console web étaient incomplètes et obsolètes. Avec cette mise à jour, le problème a été corrigé de sorte que les métriques sont correctes.
• Avant cette mise à jour, si un pipeline avait deux tâches parallèles qui échouaient et que l'une d'entre elles avait retries=2, les tâches finales ne s'exécutaient jamais, et le pipeline s'arrêtait et ne s'exécutait pas. Par exemple, la tâche pipelines-operator-subscription échouait par intermittence avec le message d'erreur suivant : Unable to connect to the server: EOF. Avec cette mise à jour, le problème a été corrigé de sorte que les tâches finales s'exécutent toujours.
• Avant cette mise à jour, si l'exécution d'un pipeline s'arrêtait en raison de l'échec d'une tâche, les autres tâches risquaient de ne pas être relancées. Par conséquent, aucune tâche finally n'était programmée, ce qui entraînait un blocage du pipeline. Cette mise à jour résout le problème. Les objets TaskRuns et Run peuvent réessayer lorsqu'une exécution du pipeline s'est arrêtée, même par arrêt gracieux, afin que les exécutions du pipeline puissent se terminer.
• Cette mise à jour modifie la façon dont les besoins en ressources sont calculés lorsqu'un ou plusieurs objets LimitRange sont présents dans l'espace de noms où un objet TaskRun existe. Le planificateur prend désormais en compte les conteneurs step et exclut tous les autres conteneurs d'applications, tels que les conteneurs sidecar, lors de la prise en compte des demandes provenant d'objets LimitRange.
• Avant cette mise à jour, dans certaines conditions, le paquetage flag pouvait analyser incorrectement une sous-commande suivant immédiatement un double tiret de terminaison de drapeau, --. Dans ce cas, il exécutait la sous-commande du point d'entrée plutôt que la commande réelle. Cette mise à jour corrige ce problème d'analyse des drapeaux afin que le point d'entrée exécute la commande correcte.
• Avant cette mise à jour, le contrôleur pouvait générer plusieurs paniques si l'extraction d'une image échouait ou si son statut d'extraction était incomplet. Cette mise à jour corrige le problème en vérifiant la valeur step.ImageID plutôt que la valeur status.TaskSpec.
• Avant cette mise à jour, l'annulation d'une exécution de pipeline contenant une tâche personnalisée non planifiée produisait une erreur PipelineRunCouldntCancel. Cette mise à jour corrige ce problème. Vous pouvez annuler une exécution de pipeline contenant une tâche personnalisée non planifiée sans produire cette erreur.

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

• Avec cette mise à jour, les ressources Trigger prennent en charge les intercepteurs personnalisés et garantissent que le port du service d'interception personnalisé est le même que celui du fichier de définition ClusterInterceptor.

• Avant cette mise à jour, la commande tkn version pour les chaînes Tekton et les composants Operator ne fonctionnait pas correctement. Cette mise à jour corrige le problème de sorte que la commande fonctionne correctement et renvoie des informations sur la version de ces composants.
• Avant cette mise à jour, si vous exécutiez une commande tkn pr delete --ignore-running et qu'un pipeline n'avait pas de valeur status.condition, l'outil CLI tkn générait une erreur de pointeur nul (NPE). Cette mise à jour corrige le problème de sorte que l'outil CLI génère désormais une erreur et ignore correctement les exécutions de pipeline qui sont toujours en cours.
• Avant cette mise à jour, si vous utilisiez les commandes tkn pr delete --keep <value> ou tkn tr delete --keep <value> et que le nombre d'exécutions de pipeline ou de tâches était inférieur à la valeur, la commande ne renvoyait pas d'erreur comme prévu. Cette mise à jour corrige le problème de sorte que la commande renvoie correctement une erreur dans ces conditions.
• Avant cette mise à jour, si vous utilisiez les commandes tkn pr delete ou tkn tr delete avec les drapeaux -p ou -t et le drapeau --ignore-running, les commandes supprimaient incorrectement les ressources en cours d'exécution ou en attente. Cette mise à jour corrige le problème de sorte que ces commandes ignorent correctement les ressources en cours d'exécution ou en attente.

• Avec cette mise à jour, vous pouvez configurer les chaînes Tekton en utilisant la ressource personnalisée TektonChain. Cette fonctionnalité permet à votre configuration de persister après la mise à jour, contrairement à la carte de configuration chains-config, qui est écrasée lors des mises à jour.
• Avec cette mise à jour, les ressources ClusterTask ne s'exécutent plus en tant que root par défaut, à l'exception des tâches de cluster buildah et s2i.
• Avant cette mise à jour, les tâches sur Red Hat OpenShift Pipelines 1.7.1 échouaient lors de l'utilisation de init comme premier argument suivi de deux arguments ou plus. Avec cette mise à jour, les drapeaux sont analysés correctement, et les exécutions de tâches sont réussies.

• 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

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

• Auparavant, la mise à niveau de Red Hat OpenShift Pipelines Operator entraînait la recréation du compte de service pipeline, ce qui signifiait que les secrets liés au compte de service étaient perdus. Cette mise à jour corrige ce problème. Lors des mises à niveau, l'Opérateur ne recrée plus le compte de service pipeline. Par conséquent, les secrets liés au compte de service pipeline persistent après les mises à niveau, et les ressources (tâches et pipelines) continuent de fonctionner correctement.
• Avec cette mise à jour, les pods Pipelines as Code s'exécutent sur les nœuds d'infrastructure si les paramètres du nœud d'infrastructure sont configurés dans la ressource personnalisée (CR) TektonConfig.

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

• Dans Tekton Chains, vous devez définir un secret appelé signing-secrets pour contenir la clé utilisée pour signer les tâches et les images. Cependant, avant cette mise à jour, la mise à jour de Red Hat OpenShift Pipelines Operator réinitialisait ou écrasait ce secret, et la clé était perdue. Cette mise à jour corrige ce problème. Désormais, si le secret est configuré après l'installation de Tekton Chains via l'Opérateur, le secret persiste et n'est pas écrasé par les mises à jour.

• 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)"

  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"]

• Avant cette mise à jour, l'installation de Red Hat OpenShift Pipelines Operator prenait plus de temps que prévu. Cette mise à jour optimise certains paramètres afin d'accélérer le processus d'installation.
• Avec cette mise à jour, les tâches des clusters Buildah et S2I comportent moins d'étapes que dans les versions précédentes. Certaines étapes ont été regroupées en une seule afin de mieux fonctionner avec les objets ResourceQuota et LimitRange et de ne pas nécessiter plus de ressources que nécessaire.
• Cette mise à jour met à jour les versions de Buildah, de l'outil CLI tkn et de l'outil CLI skopeo dans les tâches en grappe.
• Avant cette mise à jour, l'opérateur échouait lors de la création de ressources RBAC si un espace de noms était dans l'état Terminating. Avec cette mise à jour, l'opérateur ignore les espaces de noms dans l'état Terminating et crée les ressources RBAC.
• Avant cette mise à jour, les pods pour les cronjobs prune n'étaient pas planifiés sur les nœuds d'infrastructure, comme prévu. Au lieu de cela, ils étaient planifiés sur les nœuds de travail ou n'étaient pas planifiés du tout. Avec cette mise à jour, ces types de pods peuvent désormais être planifiés sur les nœuds d'infrastructure s'ils sont configurés dans la ressource personnalisée (CR) TektonConfig.

• Changement radical : Cette mise à jour supprime les champs disable-working-directory-overwrite et disable-home-env-overwrite de la ressource personnalisée (CR) TektonConfig. Par conséquent, la CR TektonConfig ne définit plus automatiquement la variable d'environnement $HOME et le paramètre workingDir. Vous pouvez toujours définir la variable d'environnement $HOME et le paramètre workingDir en utilisant les champs env et workingDir dans la définition de ressource personnalisée (CRD) Task.

• Le type de définition de ressource personnalisée (CRD) Conditions est obsolète et devrait être supprimé dans une prochaine version. Utilisez plutôt l'expression recommandée When.

• Changement radical : La ressource Triggers valide les modèles et génère une erreur si vous ne spécifiez pas les valeurs EventListener et TriggerBinding.

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

  Astuce

  Avant d'installer des tâches basées sur le catalogue Tekton sur ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) en utilisant tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont répertoriés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>

• Sur IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.

• 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"

• Le mappage implicite des paramètres transmet incorrectement les paramètres des définitions de premier niveau Pipeline ou PipelineRun aux tâches taskRef. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en ligne taskSpec. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champ enable-api-fields sur alpha dans la section pipeline de la définition de la ressource personnalisée TektonConfig.

• Avec cette mise à jour, si des métadonnées telles que labels et annotations sont présentes dans les définitions des objets Pipeline et PipelineRun, les valeurs du type PipelineRun sont prioritaires. Vous pouvez observer un comportement similaire pour les objets Task et TaskRun.
• Avec cette mise à jour, si le champ timeouts.tasks ou le champ timeouts.finally est défini sur 0, le champ timeouts.pipeline est également défini sur 0.
• Avec cette mise à jour, l'indicateur -x set est supprimé des scripts qui n'utilisent pas de shebang. Cette correction réduit les risques de fuite de données lors de l'exécution des scripts.
• Avec cette mise à jour, tout caractère backslash présent dans les noms d'utilisateur des identifiants Git est échappé par un backslash supplémentaire dans le fichier .gitconfig.

• Avec cette mise à jour, la propriété finalizer de l'objet EventListener n'est pas nécessaire pour nettoyer les logs et les cartes de configuration.
• Avec cette mise à jour, le client HTTP par défaut associé au serveur d'écoute des événements est supprimé et un client HTTP personnalisé est ajouté. En conséquence, les délais d'attente ont été améliorés.
• Avec cette mise à jour, le rôle de cluster Déclencheurs fonctionne désormais avec les références de propriétaires.
• Avec cette mise à jour, la condition de course dans l'écouteur d'événements ne se produit pas lorsque plusieurs intercepteurs renvoient des extensions.

• Avec cette mise à jour, la commande tkn pr delete n'efface pas les pipelines exécutés avec l'indicateur ignore-running.

• Avec cette mise à jour, les pods de l'opérateur ne continuent pas à redémarrer lorsque vous modifiez les paramètres d'un add-on.
• Avec cette mise à jour, le pod tkn serve CLI est planifié sur les nœuds infra, s'il n'est pas configuré dans les ressources personnalisées d'abonnement et de configuration.
• Avec cette mise à jour, les tâches de cluster avec les versions spécifiées ne sont pas supprimées lors de la mise à niveau.

• Avec cette mise à jour, vous pouvez configurer la commande start d'un pipeline ou d'une tâche pour qu'elle renvoie une chaîne formatée YAML ou JSON en utilisant l'option --output <string>, où <string> est yaml ou json. Sinon, sans l'option --output, la commande start renvoie un message convivial difficile à analyser par d'autres programmes. Le renvoi d'une chaîne au format YAML ou JSON est utile pour les environnements d'intégration continue (CI). Par exemple, après la création d'une ressource, vous pouvez utiliser yq ou jq pour analyser le message au format YAML ou JSON concernant la ressource et attendre que cette ressource soit terminée sans utiliser l'option showlog.
• Avec cette mise à jour, vous pouvez vous authentifier auprès d'un registre en utilisant le fichier d'authentification auth.json de Podman. Par exemple, vous pouvez utiliser tkn bundle push pour pousser vers un registre distant en utilisant Podman au lieu de Docker CLI.
• Avec cette mise à jour, si vous utilisez la commande tkn [taskrun | pipelinerun] delete --all, vous pouvez conserver les exécutions datant de moins d'un certain nombre de minutes en utilisant la nouvelle option --keep-since <minutes>. Par exemple, pour conserver les exécutions datant de moins de cinq minutes, vous devez saisir tkn [taskrun | pipelinerun] delete -all --keep-since 5.
• Avec cette mise à jour, lorsque vous supprimez des exécutions de tâches ou des exécutions de pipeline, vous pouvez utiliser les options --parent-resource et --keep-since en même temps. Par exemple, la commande tkn pipelinerun delete --pipeline pipelinename --keep-since 5 préserve les exécutions de pipeline dont la ressource parente est nommée pipelinename et dont l'ancienneté est inférieure ou égale à cinq minutes. Les commandes tkn tr delete -t <taskname> --keep-since 5 et tkn tr delete --clustertask <taskname> --keep-since 5 fonctionnent de la même manière pour les exécutions de tâches.
• Cette mise à jour ajoute la prise en charge des ressources de déclenchement pour qu'elles fonctionnent avec les ressources v1beta1.

• Cette mise à jour ajoute une option ignore-running aux commandes tkn pipelinerun delete et tkn taskrun delete.
• Cette mise à jour ajoute une sous-commande create aux commandes tkn task et tkn clustertask.
• Avec cette mise à jour, lorsque vous utilisez la commande tkn pipelinerun delete --all, vous pouvez utiliser la nouvelle option --label <string> pour filtrer les parcours du pipeline par étiquette. Vous pouvez également utiliser l'option --label avec = et == comme opérateurs d'égalité, ou != comme opérateur d'inégalité. Par exemple, les commandes tkn pipelinerun delete --all --label asdf et tkn pipelinerun delete --all --label==asdf suppriment toutes deux toutes les séries de pipelines portant le label asdf.
• Avec cette mise à jour, vous pouvez récupérer la version des composants Tekton installés à partir de la carte de configuration ou, si la carte de configuration n'est pas présente, à partir du contrôleur de déploiement.

• Avec cette mise à jour, les déclencheurs prennent en charge les cartes de configuration feature-flags et config-defaults pour configurer les drapeaux des fonctionnalités et définir les valeurs par défaut, respectivement.
• Cette mise à jour ajoute une nouvelle métrique, eventlistener_event_count, que vous pouvez utiliser pour compter les événements reçus par la ressource EventListener.

• 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 :

  • operator.tekton.dev/prune.schedule: Si la valeur de cette annotation est différente de la valeur spécifiée dans la définition de la ressource personnalisée TektonConfig, un nouveau travail cron est créé dans cet espace de noms.
  • operator.tekton.dev/prune.skip: Lorsqu'il est défini sur true, l'espace de noms pour lequel il est configuré ne sera pas élagué.
  • operator.tekton.dev/prune.resources: Cette annotation accepte une liste de ressources séparées par des virgules. Pour élaguer une seule ressource, telle qu'une exécution de pipeline, définissez cette annotation à "pipelinerun". Pour élaguer plusieurs ressources, telles qu'une exécution de tâche et une exécution de pipeline, définissez cette annotation à "taskrun, pipelinerun".
  • operator.tekton.dev/prune.keep: Utilisez cette annotation pour conserver une ressource sans l'élaguer.

  • operator.tekton.dev/prune.keep-since: Cette annotation permet de conserver les ressources en fonction de leur âge. La valeur de cette annotation doit être égale à l'âge de la ressource en minutes. Par exemple, pour conserver les ressources qui ont été créées il y a cinq jours au maximum, définissez keep-since sur 7200.

    Note

    Les annotations keep et keep-since s'excluent mutuellement. Pour toute ressource, vous ne devez configurer qu'une seule d'entre elles.

  • operator.tekton.dev/prune.strategy: Fixer la valeur de cette annotation à keep ou keep-since.
• Les administrateurs peuvent désactiver la création du compte de service pipeline pour l'ensemble du cluster, et empêcher l'escalade des privilèges par une mauvaise utilisation du SCC associé, qui est très similaire à anyuid.
• Vous pouvez désormais configurer les drapeaux de fonctionnalité et les composants en utilisant la ressource personnalisée (CR) TektonConfig et les CR pour les composants individuels, tels que TektonPipeline et TektonTriggers. Ce niveau de granularité permet de personnaliser et de tester des fonctionnalités alpha telles que le Tekton OCI bundle pour des composants individuels.
• Vous pouvez désormais configurer le champ optionnel Timeouts pour la ressource PipelineRun. Par exemple, vous pouvez configurer des délais séparément pour l'exécution d'un pipeline, l'exécution de chaque tâche et les tâches finally.
• Les pods générés par la ressource TaskRun définissent désormais le champ activeDeadlineSeconds des pods. Cela permet à OpenShift de les considérer comme terminés, et vous permet d'utiliser l'objet spécifiquement scoped ResourceQuota pour les pods.
• Vous pouvez utiliser les cartes de configuration pour éliminer les balises de métriques ou les types d'étiquettes sur une exécution de tâche, une exécution de pipeline, une tâche et un pipeline. En outre, vous pouvez configurer différents types de métriques pour mesurer la durée, tels qu'un histogramme, une jauge ou la dernière valeur.
• Vous pouvez définir les demandes et les limites d'un pod de manière cohérente, car Tekton prend désormais entièrement en charge l'objet LimitRange en tenant compte des champs Min, Max, Default et DefaultRequest.

• Les fonctionnalités alpha suivantes sont introduites :

  • L'exécution d'un pipeline peut maintenant s'arrêter après l'exécution des tâches finally, plutôt que d'arrêter directement l'exécution de toutes les tâches comme c'était le cas auparavant. Cette mise à jour ajoute les valeurs spec.status suivantes :

    • StoppedRunFinally arrêtera les tâches en cours d'exécution une fois qu'elles seront terminées, puis exécutera les tâches finally.
    • CancelledRunFinally annulera immédiatement les tâches en cours, puis exécutera les tâches finally.

    • Cancelled conservera le comportement antérieur fourni par le statut PipelineRunCancelled.

      Note

      Le statut Cancelled remplace le statut PipelineRunCancelled, qui est obsolète et qui sera supprimé dans la version v1.

  • Vous pouvez désormais utiliser la commande oc debug pour mettre une tâche en mode débogage, ce qui met l'exécution en pause et vous permet d'inspecter des étapes spécifiques d'un module.
  • Lorsque vous attribuez la valeur continue au champ onError d'une étape, le code de sortie de l'étape est enregistré et transmis aux étapes suivantes. Toutefois, l'exécution de la tâche n'échoue pas et l'exécution des autres étapes de la tâche se poursuit. Pour conserver le comportement existant, vous pouvez attribuer au champ onError la valeur stopAndFail.
  • Les tâches peuvent désormais accepter plus de paramètres qu'elles n'en utilisent réellement. Lorsque l'option alpha est activée, les paramètres peuvent se propager implicitement aux spécifications intégrées. Par exemple, une tâche intégrée peut accéder aux paramètres de son pipeline parent, sans définir explicitement chaque paramètre pour la tâche.
  • Si vous activez l'indicateur pour les caractéristiques alpha, les conditions des expressions When ne s'appliqueront qu'à la tâche à laquelle elle est directement associée, et non aux dépendances de la tâche. Pour appliquer les expressions When à la tâche associée et à ses dépendances, vous devez associer l'expression à chaque tâche dépendante séparément. Notez qu'à l'avenir, ce sera le comportement par défaut des expressions When dans toutes les nouvelles versions API de Tekton. Le comportement par défaut existant sera supprimé en faveur de cette mise à jour.

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

  • Pour configurer la sélection des nœuds pour le contrôleur de l'opérateur et le déploiement des webhooks, vous devez modifier les champs config.nodeSelector et config.tolerations dans la spécification de Subscription CR, après avoir installé l'opérateur.
  • Pour déployer le reste des pods du plan de contrôle d'OpenShift Pipelines sur un nœud d'infrastructure, mettez à jour le CR TektonConfig avec les champs nodeSelector et tolerations. Les modifications sont ensuite appliquées à tous les pods créés par Operator.

• Dans le CLI 0.21.0, la prise en charge de toutes les ressources v1alpha1 pour les commandes clustertask, task, taskrun, pipeline, et pipelinerun est obsolète. Ces ressources sont désormais obsolètes et seront supprimées dans une prochaine version.

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

  Important

  Changement radical : Le label status a été supprimé de la métrique eventlistener_http_duration_seconds_*. Supprimez les requêtes basées sur le label status.

• Avec la version actuelle, les fonctionnalités de v1alpha1 sont désormais obsolètes et seront supprimées dans une prochaine version. Avec cette mise à jour, vous pouvez commencer à utiliser les types d'API v1beta1 Go à la place. Les déclencheurs prennent désormais en charge la version de l'API v1beta1.

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

  Important

  Changement de rupture : Avec cette modification, la ressource EventListener ne répond plus avec un code d'état 201 Created lorsqu'elle crée des ressources. Au lieu de cela, elle répond avec un code de réponse 202 Accepted.

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

  Important

  Changement radical : Le champ podTemplate, qui a été supprimé dans le cadre de #1100, a été supprimé.

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

  Important

  Changement radical : Le champ replicas, obsolète, a été supprimé.

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

  Important

  Les champs disable-working-directory-overwrite et disable-home-env-overwrite de la CR TektonConfig sont désormais obsolètes et seront supprimés dans une prochaine version.

• 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 IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x). Pour contourner ce 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.
• Sur IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.
• Avant d'installer des tâches basées sur le catalogue Tekton sur IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) à l'aide de tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont listés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>

• 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"

• La commande tkn hub est désormais prise en charge sur les systèmes IBM Power, IBM Z et LinuxONE.

• Avant cette mise à jour, le terminal n'était pas disponible après que l'utilisateur ait exécuté une commande tkn, et l'exécution du pipeline était terminée, même si retries était spécifié. La spécification d'un délai d'attente dans l'exécution de la tâche ou du pipeline n'avait aucun effet. Cette mise à jour corrige le problème afin que le terminal soit disponible après l'exécution de la commande.
• Avant cette mise à jour, l'exécution de tkn pipelinerun delete --all supprimait toutes les ressources. Cette mise à jour empêche la suppression des ressources en cours d'exécution.
• Avant cette mise à jour, l'utilisation de la commande tkn version --component=<component> ne renvoyait pas la version du composant. Cette mise à jour corrige le problème de sorte que cette commande renvoie la version du composant.
• Avant cette mise à jour, lorsque vous utilisiez la commande tkn pr logs, elle affichait les journaux de sortie des pipelines dans le mauvais ordre des tâches. Cette mise à jour résout le problème de sorte que les journaux de PipelineRuns sont répertoriés dans l'ordre d'exécution approprié de TaskRun.

• Avant cette mise à jour, la modification de la spécification d'un pipeline en cours d'exécution pouvait empêcher l'exécution du pipeline de s'arrêter lorsqu'elle était terminée. Cette mise à jour corrige le problème en ne récupérant la définition qu'une seule fois et en utilisant ensuite la spécification stockée dans l'état pour la vérification. Cette modification réduit la probabilité d'une condition de course lorsqu'un PipelineRun ou un TaskRun fait référence à un Pipeline ou un Task qui change pendant l'exécution.
• When les valeurs d'expression peuvent désormais contenir des références à des paramètres de type tableau, comme par exemple : values: [$(params.arrayParam[*])].