CI/CD

• .gitconfig ファイル
• Basic 認証
• SSH キー認証
• 信頼されている認証局

• シークレットデータでシークレットオブジェクトを作成します。
• Pod のサービスアカウントをシークレットの参照を許可するように更新します。
• シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

手順

• 作成コマンドを使用して JSON または YAML ファイルのシークレットオブジェクトを作成できます。

  $ oc create -f <filename>

  たとえば、ローカルの .docker/config.json ファイルからシークレットを作成できます。

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

  このコマンドにより、dockerhub という名前のシークレットの JSON 仕様が生成され、オブジェクトが作成されます。

  YAML の不透明なシークレットオブジェクトの定義

  apiVersion: v1
  kind: Secret
  metadata:
    name: mysecret
  type: Opaque 1
  data:
    username: <username>
    password: <password>

  1

  opaque シークレットを指定します。

  Docker 設定の JSON ファイルシークレットオブジェクトの定義

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

  1

  シークレットが docker 設定の JSON ファイルを使用することを指定します。

  2

  docker 設定 JSON ファイルを base64 でエンコードした出力

手順

• 値を取得するフィールドの JsonPath に、fieldPath 環境変数のソースを設定します。

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

手順

• シークレットを環境変数として使用するには、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

手順

• imageOptimizationPolicy を SkipLayers に設定します。

  strategy:
    dockerStrategy:
      imageOptimizationPolicy: SkipLayers

前提条件

• 入力シークレット、設定マップ、またはその両方を BuildConfig オブジェクトに追加している。

手順

• BuildConfig オブジェクトの dockerStrategy 定義で、ビルドボリュームを volumes 配列に追加します。以下に例を示します。

  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

  必須。一意な名前

  2 6 10

  必須。マウントポイントの絶対パス。.. または : を含めないでください。こうすることで、ビルダーが生成した宛先パスと競合しなくなります。/opt/app-root/src は、多くの Red Hat S2I 対応イメージのデフォルトのホームディレクトリーです。

  3 7 11

  必須。ソースのタイプは、ConfigMap、Secret、または CSI。

  4 8

  必須。ソースの名前。

  12

  必須。一時 CSI ボリュームを提供するドライバー。

  13

  オプション: true の場合、ドライバーに読み取り専用ボリュームを提供するように指示します。

  14

  オプション: 一時 CSI ボリュームのボリューム属性。サポートされる属性キーおよび値については、CSI ドライバーのドキュメントを参照してください。

手順

• 増分ビルドを作成するには、ストラテジー定義に以下の変更を加えてこれを作成します。

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

  1

  増分ビルドをサポートするイメージを指定します。この動作がサポートされているか判断するには、ビルダーイメージのドキュメントを参照してください。

  2

  このフラグでは、増分ビルドを試行するかどうかを制御します。ビルダーイメージで増分ビルドがサポートされていない場合は、ビルドは成功しますが、save-artifacts スクリプトがないため、増分ビルドに失敗したというログメッセージが表示されます。

• アプリケーションのソースリポジトリーの .s2i/bin ディレクトリーに assemble、run、 または save-artifacts スクリプトを指定します。

• ストラテジー定義の一部として、スクリプトを含むディレクトリーの URL を指定します。以下に例を示します。

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

  1

  このパスに、run、assemble、および save-artifacts が追加されます。一部または全スクリプトがある場合、そのスクリプトが、イメージに指定された同じ名前のスクリプトの代わりに使用されます。

前提条件

• 入力シークレット、設定マップ、またはその両方を BuildConfig オブジェクトに追加している。

手順

• BuildConfig オブジェクトの sourceStrategy 定義で、ビルドボリュームを volumes 配列に追加します。以下に例を示します。

  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

手順

• customStrategy.from セクションを設定するには、以下を実行します。

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

手順

• 各シークレットを特定の場所にマウントするには、strategy YAML ファイルの secretSource および mountPath フィールドを編集します。

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

  1

  secretSource は、ビルドと同じ namespace にあるシークレットへの参照です。

  2

  mountPath は、シークレットがマウントされる必要のあるカスタムビルダー内のパスです。

• Jenkins での動的なジョブおよび実行の作成。
• イメージストリーム、イメージストリームタグまたは設定マップからのエージェント Pod テンプレートの動的作成。
• 環境変数の挿入。
• OpenShift Container Platform Web コンソールでのパイプラインの可視化。
• Jenkins Git プラグインとの統合。これにより、OpenShift Container Platform ビルドからの Jenkins Git プラグインにコミット情報が渡されます。
• シークレットを Jenkins 認証情報エントリーに同期。

• ビルド設定内のインラインの jenkinsfile フィールド。
• ソース contextDir との関連で使用する jenkinsfile の場所を参照するビルド設定内の jenkinsfilePath フィールド。

• ソースコードリポジトリー内にあるファイルの使用。
• jenkinsfile フィールドを使用してビルド設定の一部として組み込む。

• リポジトリーのルートにある jenkinsfile という名前のファイル。
• リポジトリーのソース contextDir のルートにある jenkinsfile という名前のファイル。
• ソース contextDir に関連して BuildConfig の JenkinsPipelineStrategy セクションの jenkinsfilePath フィールドで指定される名前のファイル (指定される場合)。 指定されない場合は、リポジトリーのルートにデフォルト設定されます。

• ビルド設定に Jenkins ファイルを埋め込む
• Jenkins ファイルを含む Git リポジトリーへの参照をビルド設定に追加する

手順

• ビルド時に使用される環境変数を定義するには、YAML ファイルを編集します。

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

手順

• 手動でビルドを再実行するには、以下のコマンドを入力します。

  $ oc start-build --from-build=<build_name>

手順

• stdout でビルドのログを手動でストリーミングするには、以下のコマンドを実行します。

  $ oc start-build <buildconfig_name> --follow

手順

• 必要な環境変数を指定するには、以下のコマンドを実行します。

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

手順

• 以下のコマンドを使用してソースからビルドを開始し、タグ v2 からローカル Git リポジトリーの内容をアーカイブとして送信します。

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

手順

• 複数ビルドを手動で取り消すには、以下のコマンドを入力します。

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

手順

• すべてのビルドを取り消すには、以下のコマンドを実行します。

  $ oc cancel-build bc/<buildconfig_name>

手順

• 特定の状態のすべてのビルドを取り消すには、以下のコマンドを入力します。

  $ oc cancel-build bc/<buildconfig_name>

手順

• BuildConfig の最新ビルドのログをストリーミングするには、以下のコマンドを入力します。

  $ oc logs -f bc/<buildconfig_name>

手順

• BuildConfig の特定バージョンのビルドのログをストリームするには、以下のコマンドを入力します。

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

手順

• 詳細の出力を有効にするには、BuildConfig 内の sourceStrategy または dockerStrategy の一部として BUILD_LOGLEVEL 環境変数を渡します。

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

  1

  この値を任意のログレベルに調整します。

前提条件

• 複数のイメージ変更トリガーを設定している。これらのトリガーは 1 つまたは複数のビルドがトリガーされています。

• lastTriggeredImageID: このフィールドは例では提供されず、OpenShift Container Platform 4.8 で非推奨となり、今後のリリースでは無視されます。これには、最後のビルドがこの BuildConfig からトリガーされた際に ImageStreamTag の解決されたイメージ参照が含まれます。
• paused: このフィールドは、この例では示されていませんが、この特定のイメージ変更トリガーを一時的に無効にするのに使用できます。
• from: このフィールドを使用して、このイメージ変更トリガーを駆動する ImageStreamTag を参照します。このタイプは、コア Kubernetes タイプである OwnerReference です。

手順

• シェルスクリプト:

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

  script の値は、/bin/sh -ic で実行するシェルスクリプトです。上記のように単体テストを実行する場合など、シェルスクリプトがビルドフックの実行に適している場合に、これを使用します。たとえば、上記のユニットテストを実行する場合などです。イメージのエントリーポイントを制御するか、イメージに /bin/sh がない場合は、command および/または args を使用します。

  注記

  CentOS や RHEL イメージでの作業を改善するために、追加で -i フラグが導入されましたが、今後のリリースで削除される可能性があります。

• イメージエントリーポイントとしてのコマンド:

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

  この形式では command は実行するコマンドで、Dockerfile 参照 に記載されている、実行形式のイメージエントリーポイントを上書きします。Command は、イメージに /bin/sh がない、またはシェルを使用しない場合に必要です。他の場合は、script を使用することが便利な方法になります。

• 引数のあるコマンド:

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

  この形式は command に引数を追加するのと同じです。

前提条件

• Satellite インスタンスからコンテンツをダウンロードするために、yum 互換リポジトリー設定ファイルを提供するか、これを作成する必要があります。

  サンプルリポジトリーの設定

  [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

前提条件

• エンタイトルメントキーと Satellite リポジトリー設定がビルドボリュームとして追加しておく。

• パイプライン: Groovy 構文を使用してアプリケーションをビルドし、テストし、デプロイするプロセスをすべて自動化します。
• ノード: スクリプト化されたパイプラインのオーケストレーションまたは実行できるマシン。
• ステージ: パイプラインで実行されるタスクの概念的に異なるサブセット。プラグインまたはユーザーインターフェイスは、このブロックを使用してタスクの状態または進捗を表示します。
• ステップ: コマンドまたはスクリプトを使用して、実行する正確なアクションを指定する単一タスク。

• パイプライン: 一連のタスク、並行したタスク、またはその両方。
• タスク: コマンド、バイナリー、またはスクリプトとしてのステップシーケンス。
• PipelineRun: 1 つ以上のタスクを使用したパイプラインの実行。

• TaskRun: 1 つ以上のステップを使用したタスクの実行。

  注記

  パラメーターやワークスペースなどの入力のセットを使用して PipelineRun または TaskRun を開始し、実行結果を出力およびアーティファクトのセットで開始できます。

• ワークスペース: Tekton では、ワークスペースは以下の目的に対応する概念的なブロックです。

  • 入力、出力、およびビルドアーティファクトのストレージ。
  • タスク間でデータを共有する一般的な領域。
  • シークレットに保持される認証情報のマウントポイント、設定マップに保持される設定、および組織が共有される共通のツール。
  注記

  Jenkins には、Tekton ワークスペースに直接相当するものはありません。コントロールノードは、クローン作成したコードリポジトリー、ビルド履歴、およびアーティファクトを格納するため、ワークスペースと考えることができます。ジョブが別のノードに割り当てられると、クローンされたコードと生成されたアーティファクトがそのノードに保存されますが、ビルド履歴はコントロールノードによって維持されます。

• 今回の更新により、以前のバージョンの tkn コマンドは Red Hat OpenShift Pipelines 1.10 と互換性がなくなりました。
• この更新により、Tekton CLI から Cluster および CloudEvent パイプラインリソースのサポートが削除されます。tkn pipelineresource create コマンドを使用してパイプラインリソースを作成することはできません。また、パイプラインリソースは、タスク、クラスタータスク、またはパイプラインの start コマンドでサポートされなくなりました。
• この更新により、Tekton Chains から来歴フォーマットとしての tekton が削除されます。

• Red Hat OpenShift Pipelines 1.10 では、ClusterTask コマンドが非推奨になり、将来のリリースで削除される予定です。tkn task create コマンドも、この更新で非推奨になりました。
• Red Hat OpenShift Pipelines 1.10 では、v1 API がパイプラインリソースをサポートしていないため、tkn task start コマンドで使用されたフラグ -i および -o は非推奨になりました。
• Red Hat OpenShift Pipelines 1.10 では、v1 API がパイプラインリソースをサポートしていないため、tkn pipeline start コマンドで使用されたフラグ -r は非推奨になりました。
• Red Hat OpenShift Pipelines 1.10 の更新では、openshiftDefaultEmbeddedStatus パラメーターが full 埋め込みステータスと min 埋め込みステータスの both に設定されます。デフォルトの埋め込みステータスを変更するフラグも非推奨であり、削除されます。さらに、パイプラインのデフォルトの埋め込みステータスは、将来のリリースで minimal に変更される予定です。

• この更新には、以下の下位互換性のない変更が含まれています。

  • PipelineResources クラスターの削除
  • PipelineResources クラウドイベントの削除

• クラスターのアップグレード後にパイプラインメトリック機能が動作しない場合は、回避策として次のコマンドを実行します。

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

• 今回の更新により、Crunchy PostgreSQL などの外部データベースの使用は、IBM Power、IBM Z、および {linuxoneProductName} ではサポートされなくなりました。代わりに、デフォルトの Tekton Hub データベースを使用してください。

• この更新の前は、opc pac コマンドはヘルプを表示する代わりにランタイムエラーを生成していました。今回の更新により、opc pac コマンドがヘルプメッセージを表示するように修正されました。
• この更新の前は、tkn pac create repo コマンドを実行するには、リポジトリーを作成するための webhook の詳細が必要でした。今回の更新により、GitHub アプリケーションがインストールされている場合、tkn-pac create repo コマンドは Webhook を設定しません。
• この更新の前は、Tekton Pipelines で PipelineRun リソースの作成に問題があった場合、Pipelines as Code はパイプライン実行の作成エラーを報告しませんでした。たとえば、パイプラインの実行に存在しないタスクは、ステータスを表示しません。今回の更新により、Pipelines as Code は、欠落しているタスクとともに Tekton Pipelines からの適切なエラーメッセージを表示します。
• この更新プログラムは、認証が成功した後の UI ページのリダイレクトを修正します。これで、Tekton Hub にログインしようとしたのと同じページにリダイレクトされます。
• 今回の更新では、クラスタータスク、個々のタスク、およびパイプラインに対して、これらのフラグ --all-namespaces および --output=yaml を使用した list コマンドが修正されました。
• 今回の更新により、repo.spec.url URL の末尾にあるスラッシュが削除され、GitHub からの URL と一致するようになりました。
• この更新の前は、marshalJSON 関数はオブジェクトのリストをマーシャリングしませんでした。今回の更新で、marshalJSON 関数はオブジェクトのリストをマーシャリングします。
• 今回の更新により、Pipelines as Code を使用すると、CLI ブートストラップ GitHub アプリケーションで GitHub エンタープライズの質問をバイパスできます。
• この更新により、リポジトリーに 100 人を超えるユーザーがいる場合の GitHub コラボレーターチェックが修正されます。
• 今回の更新により、タスクまたはパイプラインの sign および verify コマンドは、kubernetes 設定ファイルなしで機能するようになりました。
• 今回の更新により、namespace でプルーナーがスキップされた場合、Tekton Operator は残りのプルーナー cron ジョブをクリーンアップします。
• この更新の前に、API ConfigMap オブジェクトは、カタログ更新間隔のユーザー設定値で更新されませんでした。この更新により、Tekon Hub CR の CATALOG_REFRESH_INTERVAL API が修正されます。

• この更新プログラムは、EmbeddedStatus 関数フラグを変更するときの PipelineRunStatus の調整を修正します。この更新により、次のパラメーターがリセットされます。

  • status.runs および status.taskruns パラメーターを最小の EmbeddedStatus で nil に設定
  • full EmbeddedStatus で status.childReferences パラメーターを nil に
• 今回の更新で、ResolutionRequest CRD に変換設定が追加されました。この更新により、v1alpha1.ResolutionRequest リクエストから v1beta1.ResolutionRequest リクエストへの変換が適切に設定されます。
• この更新プログラムは、パイプラインタスクに関連付けられている重複したワークスペースをチェックします。
• この更新により、コードでリゾルバーを有効にするためのデフォルト値が修正されます。
• この更新プログラムは、リゾルバーを使用した TaskRef および PipelineRef 名の変換を修正します。

• 今回の更新では、Conditions カスタムリソース定義 (CRD) タイプが削除されました。代わりに WhenExpressions を使用します。
• 今回の更新では、Pipeline、PipelineRun、Task、Clustertask、TaskRun などの tekton.dev/v1alpha1 API パイプラインリソースのサポートが削除されました。
• 今回の更新では、tkn-pac setup コマンドが削除されました。代わりに、tkn-pac webhook add コマンドを使用して、Webhook を既存の Git リポジトリーに再度追加します。また、tkn-pac webhook update-token コマンドを使用して、Git リポジトリー内の既存のシークレットオブジェクトの個人プロバイダーアクセストークンを更新します。
• 今回の更新により、デフォルト設定でパイプラインを実行する namespace は、pod-security.kubernetes.io/enforce:privileged ラベルをワークロードに適用しません。

• Red Hat OpenShift Pipelines 1.9.0 リリースでは、ClusterTasks が非推奨となり、今後のリリースで削除される予定です。代わりに、Cluster Resolver を使用できます。
• Red Hat OpenShift Pipelines 1.9.0 リリースでは、単一の EventListener 仕様で triggers と namespaceSelector フィールドを使用することは推奨されておらず、今後のリリースで削除される予定です。これらのフィールドは、異なる EventListener 仕様では正常に使用できます。
• Red Hat OpenShift Pipelines 1.9.0 リリースでは、tkn pipelinerun describe コマンドは PipelineRun リソースのタイムアウトを表示しません。
• Red Hat OpenShift Pipelines 1.9.0 リリースでは、PipelineResource カスタムリソース (CR) が非推奨になりました。PipelineResource CR はテクノロジープレビュー機能であり、tekton.dev/v1alpha1 API の一部でした。
• Red Hat OpenShift Pipelines 1.9.0 リリースでは、クラスタータスクからのカスタムイメージパラメーターは非推奨になりました。代わりとして、クラスタータスクをコピーして、その中でカスタムイメージを使用できます。

• Red Hat OpenShift Pipelines Operator をアンインストールすると、chains-secret および chains-config config map が削除されます。これらにはユーザーデータが含まれているため、削除せずに保持する必要があります。

• Windows でコマンドの tkn pac セットを実行すると、Command finished with error: not supported by Windows. のエラーメッセージが表示される場合があります。

  回避策: NO_COLOR 環境変数を true に設定します。

• tkn pac resolve コマンドがテンプレート化されたパラメーター値を使用して機能する場合、tkn pac resolve -f <filename> | oc create -f コマンドを実行しても、想定どおりの結果が得られない場合があります。

  回避策: この問題を軽減するには、tkn pac resolve -f <filename> -o tempfile.yaml コマンドを実行して tkn pac resolve の出力を一時ファイルに保存してから、oc create -f tempfile.yaml コマンドを実行します。例: tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml。

• この更新の前は、空の配列を置き換えた後、元の配列は中のパラメーターを無効にして空の文字列を返していました。今回の更新により、この問題は解決され、元の配列は空として返されます。
• この更新の前は、パイプライン実行のサービスアカウントに重複するシークレットが存在すると、タスク Pod の作成に失敗していました。今回の更新により、この問題が解決され、サービスアカウントに重複するシークレットが存在する場合でもタスク Pod は正常に作成されるようになりました。
• この更新の前は、TaskRun の spec.StatusMessage フィールドを見ても、TaskRun がユーザーによってキャンセルされたのか、その一部である PipelineRun によってキャンセルされたのかを区別できませんでした。今回の更新により、この問題は解決され、ユーザーは TaskRun の spec.StatusMessage フィールドを見て、TaskRun のステータスを区別できるようになりました。
• この更新の前は、無効なオブジェクトの古いバージョンを削除すると、webhook の検証が削除されていました。今回の更新で、この問題は解決されました。

• 今回の更新の前は、timeouts.pipeline パラメーターを 0 に設定すると、timeouts.tasks パラメーターまたは timeouts.finally パラメーターを設定できませんでした。今回の更新で問題が解決されました。これで、timeouts.pipeline パラメーター値を設定するときに、`timeouts.tasks` パラメーターまたは timeouts.finally パラメーターのいずれかの値を設定できます。以下に例を示します。

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

• この更新の前は、別のツールが PipelineRun または TaskRun のラベルまたはアノテーションを更新すると、競合状態が発生する可能性がありました。今回の更新により、この問題は解決され、ラベルまたはアノテーションを結合できるようになりました。

• この更新の前は、ログキーにパイプラインコントローラーと同じキーはありませんでした。今回の更新により、この問題は解決され、パイプラインコントローラーのログストリームと一致するようにログキーが更新されました。ログのキーは、ts から timestamp、level から severity、message から msg に変更されました。

• この更新の前は、PipelineRun が不明ステータスで削除された場合、エラーメッセージは生成されませんでした。今回の更新により、この問題は解決され、エラーメッセージが生成されるようになります。
• この更新の前は、list や push などのバンドルコマンドにアクセスするには、kubeconfig ファイルを使用する必要がありました。今回の更新により、この問題は解決され、kubeconfig ファイルはバンドルコマンドにアクセスする必要がなくなりました。
• この更新の前は、TaskRun の削除中に親の PipelineRun が実行されていた場合、TaskRun が削除されていました。今回の更新により、この問題は解決され、親 PipelineRun が実行されていても TaskRuns は削除されなくなりました。
• この更新の前は、ユーザーがパイプラインコントローラーで許可されているよりも多くのオブジェクトを含むバンドルのビルドを試みた場合、Tekton CLI はエラーメッセージを表示しませんでした。今回の更新により、この問題は解決され、ユーザーがパイプラインコントローラーで許可されている制限を超える数のオブジェクトを含むバンドルを構築しようとすると、Tekton CLI にエラーメッセージが表示されるようになります。

• この更新の前は、クラスターから namespace が削除されても、operator は ClusterInterceptor ClusterRoleBinding サブジェクトから namespace を削除しませんでした。今回の更新により、この問題は解決され、operator は ClusterInterceptor ClusterRoleBinding サブジェクトから namespace を削除するようになります。
• この更新の前は、デフォルトの Red Hat OpenShift Pipelines Operator インストールで、pipelines-scc-rolebinding security context constraint (SCC) ロールバインディングリソースがクラスターに残りました。今回の更新により、デフォルトの Red Hat OpenShift Pipelines Operator インストールで、pipelines-scc-rolebinding security context constraint (SCC) ロールバインディングリソースがクラスターから削除されるようになります。

• この更新の前は、Pipelines as Code は Pipelines as Code ConfigMap オブジェクトから更新された値を取得しませんでした。今回の更新により、この問題は修正され、Pipelines as Code ConfigMap オブジェクトが新しい変更を検索するようになります。
• この更新の前は、Pipelines as Code コントローラーは tekton.dev/pipeline ラベルが更新されるのを待たずに checkrun id ラベルを追加して、競合状態を引き起こしていました。今回の更新により、Pipelines as Code コントローラーは tekton.dev/pipeline ラベルが更新されるのを待ってから checkrun id ラベルを追加するようになりました。これは、競合状態の回避に役立ちます。
• この更新の前は、git リポジトリーに PipelineRun がすでに存在する場合、tkn-pac create repo コマンドはそれをオーバーライドしませんでした。今回の更新では tkn-pac create コマンドが修正され、git リポジトリーに PipelineRun が存在する場合はそれをオーバーライドするようになり、問題は解決されました。
• この更新の前は、tkn pac describe コマンドはすべてのメッセージの理由を表示しませんでした。今回の更新により、この問題は修正され、tkn pac describe コマンドはすべてのメッセージの理由を表示するようになります。
• この更新の前は、アノテーションのユーザーが refs/head/rel-* などの正規表現形式を使用して値を指定した場合、プルリクエストは失敗していました。ベースブランチに refs/heads がないため、プルリクエストは失敗していました。今回の更新では接頭辞が追加され、一致するかどうかもチェックされます。これで問題が解決し、プルリクエストが成功するようになります。

• この更新の前は、tkn pac repo list コマンドは Microsoft Windows で実行できませんでした。今回の更新で問題が修正され、Microsoft Windows で tkn pac repo list コマンドを実行できるようになりました。
• この更新の前は、Pipelines as Code ウォッチャーは設定変更イベントをすべて受信するわけではありませんでした。今回の更新により、Pipelines as Code ウォッチャーが更新され、Pipelines as Code ウォッチャーが設定変更イベントを見逃さなくなりました。
• この更新の前は、Pipelines as Code によって作成された TaskRuns や PipelineRuns などの Pod は、クラスター内のユーザーによって公開されたカスタム証明書にアクセスできませんでした。今回の更新で問題が修正され、クラスター内で TaskRuns または PipelineRuns Pod からカスタム証明書にアクセスできるようになりました。
• この更新の前は、FIPS が有効になっているクラスターで、Trigger リソースで使用される tekton-triggers-core-interceptors コアインターセプターは、Pipelines Operator がバージョン 1.9 にアップグレードされた後に機能しませんでした。今回の更新で問題が解決されました。現在、OpenShift はすべてのコンポーネントに MInTLS 1.2 を使用しています。その結果、tekton-triggers-core-interceptors コアインターセプターが TLS バージョン 1.2 に更新され、その機能は正確に実行されるようになりました。

• この更新の前は、内部 OpenShift イメージレジストリーでパイプライン実行を使用する場合、パイプライン実行定義でイメージへの URL をハードコーディングする必要がありました。以下に例を示します。

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

  Pipelines as Code のコンテキストでパイプライン実行を使用する場合、ハードコーディングされた値により、異なるクラスターおよび namespace でパイプライン実行定義をしようできませんでした。

  今回の更新により、namespace とパイプライン実行名の値をハードコーディングする代わりに動的テンプレート変数を使用して、パイプライン実行定義を一般化できます。以下に例を示します。

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

• この更新の前は、Pipelines as Code は同じ GitHub トークンを使用して、デフォルトの GitHub ブランチの同じホストでのみ使用可能なリモートタスクを取得していました。今回の更新で問題が解決されました。Pipelines as Code は同じ GitHub トークンを使用して、任意の GitHub ブランチからリモートタスクを取得するようになりました。

• Tekton Hub CR で使用される Hub API ConfigMap オブジェクト内のフィールドである CATALOG_REFRESH_INTERVAL の値が、ユーザーが指定したカスタム値で更新されません。

  回避策: なし。問題 SRVKP-2854 を確認してください。

• 今回の更新で、OpenShift Container Platform のアップグレードを妨げる OLM のご設定の問題が発生しました。この問題は今後のリリースで修正される予定です。

• この更新前は、リリースの以前のバージョンで OLM の誤設定の問題が発生しており、OpenShift Container Platform のアップグレードが妨げられていました。今回の更新により、この誤設定の問題が修正されました。

• 今回の更新により、大規模パイプラインのパフォーマンスの問題が修正されました。これにより、CPU 使用率は 61%、メモリー使用率は 44% 削減されました。
• この更新前は、when 式が原因でタスクが実行されない場合、パイプラインの実行は失敗していました。今回の更新により、パイプライン結果でスキップされたタスクの結果が検証されないようにすることで問題を修正しました。現在は、パイプラインの結果は出力されず、結果の欠落を原因とするパイプライン実行の失敗は発生しません。
• 今回の更新により、pipelineref.bundle を v1beta1 API のバンドルリゾルバーに変換する動作が修正されました。現在は変換機能により、変換後に kind フィールドの値が Pipeline に設定されます。
• この更新前は、Pipelines Operator の問題により、ユーザーは spec.pipeline.enable-api-fields フィールドの値を beta に設定できませんでした。今回の更新でこの問題が修正されています。現在は、TektonConfig カスタムリソースで値を alpha、stable、beta に設定できます。
• この更新前は、Pipelines as Code はクラスターエラーが原因でシークレットを作成できなかった場合、GitHub チェック実行でパブリックな一時トークンが表示されていました。今回の更新でこの問題が修正されています。現在は、シークレットの作成に失敗しても、GitHub チェックインターフェイスにトークンは表示されません。

• 現在、OpenShift Container Platform Web コンソールでのパイプライン実行の stop オプションに関する既知の問題があります。Actions ドロップダウンリストの stop オプションが期待どおりに機能せず、パイプラインの実行がキャンセルされません。

• 現在、カスタムリソース定義の変換の失敗が原因で発生する、Pipelines バージョン 1.9.x へのアップグレードに関する既知の問題があります。

  回避策: Pipelines バージョン 1.9.x にアップグレードする前に、Red Hat カスタマーポータルの solution に記載されている手順を実行してください。

• この更新により、TaskRun および PipelineRun リソースのデフォルトのメトリックレベルが次の値に変更されます。

  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"

• 今回の更新により、アノテーションまたはラベルが Pipeline および PipelineRun リソースの両方にある場合、Run タイプの値が優先されます。アノテーションまたはラベルが Task および TaskRun リソースにある場合も同様です。
• Red Hat OpenShift Pipelines 1.8 では、以前に非推奨の PipelineRun.Spec.ServiceAccountNames フィールドが削除されました。代わりに PipelineRun.Spec.TaskRunSpecs フィールドを使用してください。
• Red Hat OpenShift Pipelines 1.8 では、以前に非推奨の TaskRun.Status.ResourceResults.ResourceRef フィールドが削除されました。代わりに TaskRun.Status.ResourceResults.ResourceName フィールドを使用してください。
• Red Hat OpenShift Pipelines 1.8 では、以前に非推奨となった Conditions リソースタイプが削除されました。Conditions リソースを、これが含まれる Pipeline リソース定義から削除します。代わりに PipelineRun 定義で when 式を使用してください。

• Tekton Chains では、tekton-provenance 形式は本リリースで削除されました。代わりに、TektonChain カスタムリソースで "artifacts.taskrun.format": "in-toto" を設定して、in-toto 形式を使用します。

• Pipeline が Code 0.5.x として同梱される Red Hat OpenShift Pipelines 1.7.x。現在の更新には、Pipeline が Code 0.10.x として同梱されます。この変更により、新規コントローラーの openshift-pipelines namespace に新規ルートが作成されます。このルートは、Pipeline を Code として使用する GitHub Apps または Webhook で更新する必要があります。ルートを取得するには、以下のコマンドを使用します。

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

• 今回の更新で、コードとしてのパイプラインは、Repository カスタムリソース定義 (CRD) のデフォルトの秘密鍵の名前を変更します。CRD で、token を provider.token に置き換え、secret を webhook.secret に置き換えます。
• 今回の更新で、Pipelines as Code は、特別なテンプレート変数を、プライベートリポジトリーの複数のパイプライン実行をサポートするものに置き換えます。パイプラインの実行で、secret: pac-git-basic-auth-{{repo_owner}}-{{repo_name}} を secret: {{ git_auth_secret }} に置き換えます。

• 今回の更新により、コードとしての Pipeline が tkn-pac CLI ツールで以下のコマンドを更新するようになりました。

  • tkn pac repository create を tkn pac create repository に置き換えます。
  • tkn pac repository delete を tkn pac delete repository に置き換えます。
  • tkn pac repository list を tkn pac list に置き換えます。

• OpenShift Container Platform 4.11 以降、Red Hat OpenShift Pipelines Operator をインストールおよびアップグレードするための preview および stable チャネルは削除されています。Operator をインストールしてアップグレードするには、適切な pipelines-<version> チャネル、または最新の安定バージョンの latest チャネルを使用します。たとえば、Pipelines Operator バージョン 1.8.x をインストールするには、pipelines-1.8 チャネルを使用します。

  注記

  OpenShift Container Platform 4.10 以前のバージョンでは、preview および stable チャンネルを使用して Operator をインストールおよびアップグレードできます。

• Red Hat OpenShift Pipelines GA 1.6 で廃止された tekton.dev/v1alpha1 API バージョンのサポートは、今後の Red Hat OpenShift Pipelines GA 1.9 リリースで削除される予定です。

  この変更は、TaskRun、PipelineRun、Task、Pipeline、および同様の tekton.dev/v1alpha1 リソースを含むパイプラインコンポーネントに影響します。別の方法として、 Migrating From Tekton v1alpha1 to Tekton v1beta1 で説明されているように、既存のリソースを apiVersion: tekton.dev/v1beta1 を使用するように更新します。

  tekton.dev/v1alpha1 API バージョンのバグ修正とサポートは、現在の GA 1.8 ライフサイクルの終了までのみ提供されます。

  重要

  Tekton Operator の場合、operator.tekton.dev/v1alpha1 API バージョンは 非 推奨ではありません。この値を変更する必要はありません。

• Red Hat OpenShift Pipelines 1.8 では、PipelineResource カスタムリソース (CR) が利用可能ですが、サポートされなくなりました。PipelineResource CR は Tech Preview 機能であり、tekton.dev/v1alpha1 API の一部であり、廃止予定であり、今後の Red Hat OpenShift Pipelines GA 1.9 リリースで削除される予定でした。
• Red Hat OpenShift Pipelines 1.8 では、Condition カスタムリソース (CR) が削除されています。Condition CR は tekton.dev/v1alpha1 API の一部でしたが、これは非推奨であり、今後の Red Hat OpenShift Pipelines GA 1.9 リリースで削除される予定です。
• Red Hat OpenShift Pipelines 1.8 では、gsutil の gcr.io イメージが削除されました。この削除により、このイメージに依存する Pipeline リソースを含むクラスターが壊れる可能性があります。バグ修正とサポートは、Red Hat OpenShift Pipelines 1.7 ライフサイクルが終了するまでのみ提供されます。

• Red Hat OpenShift Pipelines 1.8 では、PipelineRun.Status.TaskRuns および PipelineRun.Status.Runs フィールドは非推奨となり、将来のリリースで削除される予定です。TEP-0100: PipelineRuns に埋め込まれた TaskRuns と Runs Status を参照してください。

• Red Hat OpenShift Pipelines 1.8 では、pipelineRunCancelled 状態は非推奨となり、今後のリリースで削除される予定です。PipelineRun オブジェクトの正常な終了は、アルファ機能から安定した機能にプロモートされるようになりました。(TEP-0058: パイプライン実行の正常な終了 を参照してください。) 別の方法として、Cancelled 状態を使用できます。これは pipelineRunCancelled 状態を置き換えます。

  Pipeline および Task リソースを変更する必要はありません。パイプラインの実行をキャンセルするツールがある場合は、次のリリースでツールを更新する必要があります。この変更は、CLI、IDE 拡張機能などのツールにも影響を与え、新しい PipelineRun ステータスをサポートするようにします。

  この機能はデフォルトで使用できるため、TektonConfig カスタムリソース定義で pipeline.enable-api-fields フィールドを alpha に設定する必要がなくなりました。

• Red Hat OpenShift Pipelines 1.8 では、PipelineRun の timeout フィールドが非推奨になりました。代わりに、PipelineRun.Timeouts フィールドを使用してください。これは現在、アルファ機能から安定した機能に昇格しています。

  この機能はデフォルトで使用できるため、TektonConfig カスタムリソース定義で pipeline.enable-api-fields フィールドを alpha に設定する必要がなくなりました。

• Red Hat OpenShift Pipelines 1.8 では、init コンテナーは LimitRange オブジェクトのデフォルトのリクエスト計算から省略されています。

• s2i-nodejs パイプラインは、nodejs:14-ubi8-minimal イメージストリームを使用して、source-to-image (S2I) ビルドを実行できません。そのイメージストリームを使用すると error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127 メッセージが生成されます。

  回避策: nodejs:14-ubi8-minimal イメージストリームではなく、nodejs:14-ubi8 を使用します。

• Maven および Jib Maven クラスタータスクを実行する場合には、デフォルトのコンテナーイメージは Intel(x86) アーキテクチャーでのみサポートされます。したがって、タスクは ARM、IBM Power Systems (ppc64le)、IBM Z、および LinuxONE (s390x) クラスターで失敗します。

  回避策: MAVEN_IMAGE パラメーター値を maven:3.6.3-adoptopenjdk-11 に設定して、カスタムイメージを指定します。

  ヒント

  tkn hub を使用して、ARM、IBM Power Systems (ppc64le)、IBM Z、および LinuxONE (s390x) に Tekton カタログに基づくタスクをインストールする前に、これらのプラットフォームでタスクを実行できるかどうかを確認してください。ppc64le および s390x がタスク情報の Platforms セクションに一覧表示されているかどうかを確認するには、tkn hub info task <name> コマンドを実行します。

• ARM、IBM Power Systems、IBM Z、および LinuxONE では、s2i-dotnet クラスタータスクはサポートされていません。

• 暗黙的なパラメーターマッピングは、最上位の Pipeline または PipelineRun 定義から taskRef タスクにパラメーターを誤って渡します。マッピングは、トップレベルのリソースからインライン taskSpec 仕様のタスクにのみ行う必要があります。この問題は、TektonConfig カスタムリソース定義の pipeline セクションで enable-api-fields フィールドを alpha に設定することにより、この機能が有効になっているクラスターにのみ影響します。

• この更新の前は、Web コンソールの開発者ビューでのパイプライン実行のメトリックは不完全で古くなっていました。今回の更新で問題が修正され、指標が正しくなりました。
• この更新の前は、パイプラインに失敗した 2 つの並列タスクがあり、そのうちの 1 つが retries=2 であった場合、最後のタスクは実行されず、パイプラインはタイムアウトして実行に失敗しました。たとえば、pipelines-operator-subscription タスクが次のエラーメッセージで断続的に失敗しました。Unable to connect to the server: EOF。今回の更新で、最終タスクが常に実行されるように問題が修正されました。
• この更新の前は、タスクの実行が失敗したためにパイプラインの実行が停止した場合、他のタスクの実行が再試行を完了しない可能性がありました。その結果、finally タスクがスケジュールされず、パイプラインがハングしました。 今回の更新で問題が解決されました。TaskRuns および Run オブジェクトは、パイプラインの実行が停止したときに (正常な停止によっても) 再試行できるため、パイプラインの実行を完了できます。
• この更新により、TaskRun オブジェクトが存在する namespace に 1 つ以上の LimitRange オブジェクトが存在する場合のリソース要件の計算方法が変更されます。スケジューラーは、step コンテナーを考慮し、LimitRange オブジェクトからの要求を因数分解するときに、サイドカーコンテナーなどの他のすべてのアプリコンテナーを除外するようになりました。
• この更新の前は、特定の条件下で、フラグパッケージが二重ダッシュフラグターミネータ -- の直後のサブコマンドを誤って解析する場合がありました。その場合、実際のコマンドではなく、エントリーポイントサブコマンドが実行されました。今回の更新では、このフラグ解析の問題が修正され、エントリーポイントが正しいコマンドを実行できるようになりました。
• この更新の前は、イメージのプルが失敗した場合、またはそのプルステータスが不完全であった場合、コントローラーが複数のパニックを生成する可能性がありました。この更新では、status.TaskSpec 値ではなく step.ImageID 値をチェックすることで問題が修正されています。
• この更新の前は、スケジュールされていないカスタムタスクを含むパイプラインの実行をキャンセルすると、PipelineRunCouldntCancel エラーが発生していました。今回の更新でこの問題が修正されています。エラーを生成することなく、スケジュールされていないカスタムタスクを含むパイプラインの実行をキャンセルできます。

• この更新の前は、$params["<NAME>"] または $params['<NAME>'] の <NAME> にドット文字 (.) が含まれている場合、ドットの右側の名前のどの部分も含まれていませんでした。たとえば、$params["org.ipsum.lorem"] から、org のみが抽出されました。

  今回の更新で問題が修正され、$params が完全な値を取得するようになりました。たとえば、$params["org.ipsum.lorem"] と $params['org.ipsum.lorem'] は有効で、<NAME> の値全体である org.ipsum.lorem が抽出されます。

  <NAME> が一重引用符または二重引用符で囲まれていない場合にも、エラーが出力されます。たとえば、$params.org.ipsum.lorem は有効ではなく、検証エラーが発生します。

• 今回の更新により、Trigger リソースはカスタムインターセプターをサポートし、カスタムインターセプターサービスのポートが ClusterInterceptor 定義ファイルのポートと同じになるようにします。

• この更新の前は、Tekton Chains および Operator コンポーネントの tkn version コマンドが正しく機能しませんでした。今回の更新で問題が修正され、コマンドが正しく機能し、それらのコンポーネントのバージョン情報が返されるようになりました。
• この更新の前に、tkn pr delete --ignore-running コマンドを実行し、パイプラインの実行に status.condition 値がない場合、tkn CLI ツールは null-pointer エラー (NPE) を生成しました。今回の更新で問題が修正され、CLI ツールがエラーを生成し、実行中のパイプライン実行を正しく無視するようになりました。
• この更新の前に、tkn pr delete --keep <value> または tkn tr delete --keep <value> コマンドを使用し、パイプラインの実行またはタスクの実行の数が値よりも少ない場合、コマンドは予想通りのエラー。今回の更新で問題が修正され、これらの条件下でコマンドが正しくエラーを返すようになりました。
• この更新の前に、-p または -t フラグと --ignore-running フラグを指定して tkn pr delete または tkn tr delete コマンドを使用した場合、コマンドは実行中または保留中のリソースを誤って削除しました。今回の更新で問題が修正され、これらのコマンドが実行中または保留中のリソースを正しく無視するようになりました。

• 今回の更新により、TektonChain カスタムリソースを使用して Tekton Chains を設定できるようになりました。この機能により、アップグレード中に上書きされる chain-config 設定マップとは異なり、アップグレード後も設定を維持できます。
• 今回の更新により、buildah および s2i クラスタータスクを除き、ClusterTask リソースはデフォルトで root として実行されなくなりました。
• 今回の更新前は、最初の引数として init を使用し、その後に 2 つ以上の引数を使用すると、Red Hat OpenShift Pipelines 1.7.1 でのタスクが失敗していました。今回の更新により、フラグが正しく解析され、タスクが正常に実行されるようになりました。

• 今回の更新以前は、無効なロールバインディングにより、OpenShift Container Platform 4.9 および 4.10 への Red Hat OpenShift Pipelines Operator のインストールは、以下のエラーメッセージと共に失敗していました。

  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

  今回の更新で問題が修正され、障害が発生しなくなりました。

• 以前は、Red Hat OpenShift Pipelines Operator をアップグレードすると pipeline サービスアカウントが再作成され、サービスアカウントにリンクされたシークレットが失われていました。今回の更新でこの問題が修正されています。アップグレード中に、Operator は pipeline サービスアカウントを再作成しなくなりました。その結果、pipeline サービスアカウントにアタッチされたシークレットはアップグレード後も保持され、リソース (タスクとパイプライン) は引き続き正しく機能します。
• 今回の更新により、TektonConfig カスタムリソース (CR) でインフラストラクチャーノード設定が設定されている場合、Pipelines as Code Pod はインフラストラクチャーノードで実行されます。

• 以前は、リソースプルーナーを使用して、各 namespace Operator が個別のコンテナーで実行されるコマンドを作成していました。この設計は、namespaces の数が多いクラスターで大量のリソースを消費しました。たとえば、1 つのコマンドを実行するために、1000 個の namespace を持つクラスターは、Pod 内に 1000 個のコンテナーを生成しました。

  今回の更新でこの問題が修正されています。すべてのコマンドがループ内の 1 つのコンテナーで実行されるように、namespace ベースの設定をジョブに渡します。

• Tekton Chains では、signing-secrets と呼ばれるシークレットを定義して、タスクとイメージの署名に使用されるキーを保持する必要があります。ただし、この更新の前に、Red Hat OpenShift Pipelines Operator を更新すると、このシークレットがリセットまたは上書きされ、キーが失われました。今回の更新でこの問題が修正されています。これで、Operator を介して Tekton Chains をインストールした後にシークレットが設定された場合、シークレットは保持され、アップグレードによって上書きされなくなりました。

• 今回の更新以前は、すべての S2I ビルドタスクが以下の様なエラーメッセージと共に失敗していました。

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

  今回の更新により、pipelines-scc セキュリティーコンテキスト制約 (SCC) は、Buildah および S2I クラスタータスクに必要な SETFCAP 機能と互換性が確保されています。その結果、Buildah および S2I ビルドタスクを正常に実行できます。

  さまざまな言語やフレームワークで書かれたアプリケーションに対して Buildah クラスタータスクおよび S2I ビルドタスクを正常に実行するには、build や push などの適切な steps オブジェクトに以下のスニペットを追加します。

  securityContext:
    capabilities:
      add: ["SETFCAP"]

• 今回の更新前は、Red Hat OpenShift Pipelines Operator のインストールに予想以上に時間がかかりました。この更新プログラムは、インストールプロセスを高速化するために一部の設定を最適化します。
• 今回の更新により、Buildah および S2I クラスタータスクの手順が以前のバージョンよりも少なくなりました。一部のステップは 1 つのステップに結合されているため、ResourceQuota および LimitRange オブジェクトでより適切に機能し、必要以上のリソースを必要としません。
• この更新により、クラスタータスクの Buildah、tkn CLI ツール、および skopeo CLI ツールのバージョンがアップグレードされます。
• 今回の更新前は、いずれかの namespace が Terminating 状態の場合、RBAC リソースの作成時に Operator が失敗していました。今回の更新により、Operator は Terminating 状態の namespace を無視し、RBAC リソースを作成します。
• この更新の前は、予想どおり、prune cronjobs の Pod がインフラストラクチャーノードでスケジュールされていませんでした。代わりに、それらはワーカーノードでスケジュールされているか、まったくスケジュールされていませんでした。今回の更新により、TektonConfig カスタムリソース (CR) で設定されている場合、これらのタイプの Pod をインフラストラクチャーノードでスケジュールできるようになりました。

• 重大な変更: この更新により、TektonConfig カスタムリソース (CR) から disable-working-directory-overwrite および disable-home-env-overwrite フィールドが削除されます。その結果、TektonConfig CR は $HOME 環境変数と workingDir パラメーターを自動的に設定しなくなりました。タスク カスタムリソース定義 (CRD) の env および workingDir フィールドを使用して、引き続き $HOME 環境変数と workingDir パラメーターを設定できます。

• Conditions カスタムリソース定義 (CRD) タイプは非推奨であり、将来のリリースで削除される予定です。代わりに、推奨される When 式を使用してください。

• 重大な変更: EventListener と TriggerBinding の値を指定しない場合、Triggers リソースはテンプレートを検証し、エラーを生成します。

• Maven および Jib Maven クラスタータスクを実行する場合には、デフォルトのコンテナーイメージは Intel(x86) アーキテクチャーでのみサポートされます。したがって、タスクは ARM、IBM Power Systems (ppc64le)、IBM Z、および LinuxONE (s390x) クラスターで失敗します。回避策として、MAVEN_IMAGE パラメーターの値を maven:3.6.3-adoptopenjdk-11 に設定すると、カスタムイメージを指定できます。

  ヒント

  tkn hub を使用して、ARM、IBM Power Systems (ppc64le)、IBM Z、および LinuxONE (s390x) に Tekton カタログに基づくタスクをインストールする前に、これらのプラットフォームでタスクを実行できるかどうかを確認してください。ppc64le および s390x がタスク情報の Platforms セクションに一覧表示されているかどうかを確認するには、tkn hub info task <name> コマンドを実行します。

• IBM Power Systems、IBM Z、および LinuxONE では、s2i-dotnet クラスタータスクはサポートされません。

• nodejs:14-ubi8-minimal イメージストリームを使用すると、以下のエラーが生成されるため、使用できません。

  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"

• 暗黙的なパラメーターマッピングは、最上位の Pipeline または PipelineRun 定義から taskRef タスクにパラメーターを誤って渡します。マッピングは、トップレベルのリソースからインライン taskSpec 仕様のタスクにのみ行う必要があります。この問題は、TektonConfig カスタムリソース定義の pipeline セクションで enable-api-fields フィールドを alpha に設定することにより、この機能が有効になっているクラスターにのみ影響します。

• 今回の更新では、labels や annotations などのメタデータが Pipeline オブジェクト定義と PipelineRun オブジェクト定義の両方に存在する場合、PipelineRun タイプの値が優先されます。Task オブジェクトと TaskRun オブジェクトで同様の動作が見られます。
• この更新では、timeouts.tasks フィールドまたは timeouts.finally フィールドが 0 に設定されている場合、timeouts.pipeline も 0 に設定されます。
• この更新により、シバンを使用しないスクリプトから -x セットフラグが削除されました。この修正により、スクリプト実行による潜在的なデータ漏洩が減少します。
• この更新により、Git クレデンシャルのユーザー名に存在するバックスラッシュ文字は、.gitconfig ファイルの追加のバックスラッシュでエスケープされます。

• この更新により、EventListener オブジェクトの finalizer プロパティーは、ロギングおよび設定マップのクリーンアップに必要なくなりました。
• この更新により、イベントリスナーサーバーに関連付けられているデフォルトの HTTP クライアントが削除され、カスタム HTTP クライアントが追加されます。その結果、タイムアウトが改善されました。
• この更新により、トリガークラスターのロールが所有者の参照で機能するようになりました。
• この更新では、複数のインターセプターが拡張機能を返す場合、イベントリスナーの競合状態は発生しません。

• この更新により、tkn pr delete コマンドは、ignore-running フラグで実行されているパイプラインを削除しません。

• この更新では、アドオンパラメーターを変更しても、Operator Pod は再起動し続けません。
• この更新により、サブスクリプションおよび設定カスタムリソースで設定されていない場合、tkn serve CLI Pod はインフラノードでスケジュールされます。
• この更新では、指定されたバージョンのクラスタータスクはアップグレード中に削除されません。

• 今回の更新により --output <string> を使用して、YAML または JSON 形式の文字列を返すようにパイプラインまたはタスクの start コマンドを設定できるようになりました。ここでは、<string> は yaml または json に置き換えます。--output オプションを指定しないと、start コマンドは人間による解読はしやすくなりますが、他のプログラムによる解析が難しいメッセージを返します。継続的インテグレーション (CI) 環境では、YAML または JSON 形式の文字列を返す機能は便利です。たとえば、リソースの作成後に yq または jq を使用して、リソースに関する YAML または JSON 形式のメッセージを解析し、showlog オプションを使用せずにそのリソースが終了するまで待機します。
• 今回の更新により、Podman の auth.json 認証ファイルを使用してレジストリーに対して認証できるようになりました。たとえば、tkn bundle push を使用して、Docker CLI ではなく Podman を使用してリモートレジストリーにプッシュできます。
• 今回の更新により、tkn [taskrun | pipelinerun] delete --all コマンドを使用すると、新規の --keep-since <minutes> オプションを使用して、指定した期間よりも後の実行を保持できます。たとえば、5 分未満の実行を維持するには、tkn [taskrun | pipelinerun] delete -all --keep-since 5 を入力します。
• 今回の更新により、タスク実行またはパイプライン実行を削除する際に、--parent-resource と --keep-since オプションを同時に使用できるようになりました。たとえば、tkn pipelinerun delete --pipeline pipelinename --keep-since 5 コマンドは、親リソースの名前が pipelinename で、その経過時間が 5 分以下であるパイプラインの実行を保持します。tkn tr delete -t <taskname> --keep-since 5 および tkn tr delete --clustertask <taskname> --keep-since 5 コマンドはタスク実行と同様に機能します。
• 今回の更新により、v1beta1 リソースと連携するトリガーリソースのサポートが追加されました。

• 今回の更新により、ignore-running オプションが tkn pipelinerun delete および tkn taskrun delete コマンドに追加されています。
• 今回の更新により、create サブコマンドが tkn task と tkn clustertask コマンドに追加されました。
• 今回の更新により、tkn pipelinerun delete --all コマンドを使用すると、新規の --label <string> オプションを使用して、ラベルでパイプライン実行をフィルターできるようになりました。オプションで、--label オプションに = と == を等価演算子として、または != を不等価演算子として指定して使用できます。たとえば、tkn pipelinerun delete --all --label asdf および tkn pipelinerun delete --all --label==asdf コマンドはどちらも、asdf ラベルが割り当てられたすべてのパイプライン実行を削除します。
• 今回の更新では、設定マップからインストールされた Tekton コンポーネントのバージョンを取得するか、設定マップがない場合はデプロイメントコントローラーから取得できるようになりました。

• 今回の更新では、機能フラグを設定し、デフォルト値をそれぞれ設定するために feature-flags と config-defaults 設定マップをサポートするようになりました。
• 今回の更新では、新しいメトリクス eventlistener_event_count が追加され、EventListener リソースが受信するイベントをカウントできるようになりました。

• 今回の更新では、v1beta1 Go API タイプが追加されました。今回の更新では、トリガーが v1beta1 API バージョンをサポートするようになりました。

  現在のリリースでは、v1alpha1 機能が非推奨となり、今後のリリースで削除されます。代わりに v1beta1 機能の使用を開始します。

• 現在のリリースでは、リソースの自動実行がデフォルトで有効になっています。さらに、以下の新規アノテーションを使用して、namespace ごとにタスク実行およびパイプライン実行を自動実行するように設定できます。

  • operator.tekton.dev/prune.schedule: このアノテーションの値が TektonConfig カスタムリソース定義で指定された値と異なる場合には、その namespace に新規の cron ジョブが作成されます。
  • operator.tekton.dev/prune.skip: true に設定されている場合、設定先の namespace はプルーニングされません。
  • operator.tekton.dev/prune.resources: このアノテーションではリソースのコンマ区切りのリストを使用できます。パイプライン実行などの単一リソースをプルーニングするには、このアノテーションを pipelinerun に設定します。task run や pipeline run などの複数のリソースをプルーニングするには、このアノテーションを "taskrun, pipelinerun" に設定します。
  • operator.tekton.dev/prune.keep: このアノテーションを使用して、プルーニングなしでリソースを保持します。

  • operator.tekton.dev/prune.keep-since: このアノテーションを使用して、経過時間をもとにリソースを保持します。このアノテーションの値は、リソースの経過時間 (分単位) と等しくなければなりません。たとえば、6 日以上前に作成されたリソースを保持するには、keep-since を 7200 に設定します。

    注記

    keep および keep-since アノテーションは同時に使用できません。リソースには、どちらか 1 つだけを使用する必要があります。

  • operator.tekton.dev/prune.strategy: このアノテーションの値を keep または keep-since のいずれかに設定します。
• 管理者はクラスター全体に対する pipeline サービスアカウントの作成を無効にし、紐付けされた SCC (anyuid と非常に似ている) の悪用による権限昇格を防ぎます。
• TektonConfig カスタムリソース (CR) および、TektonPipeline と TektonTriggers などの個々のコンポーネントの CR を使用して、機能フラグおよびコンポーネントを設定できるようになりました。この詳細レベルは、個々のコンポーネントの Tekton OCI バンドルなどのアルファ機能のカスタマイズおよびテストに役立ちます。
• PipelineRun リソースのオプションの Timeouts フィールドを設定できるようになりました。たとえば、パイプライン実行、各タスク実行、および finally タスクに個別にタイムアウトを設定できます。
• TaskRun リソースで生成される Pod を使用して、Pod の activeDeadlineSeconds フィールドが設定されるようになりました。これにより、OpenShift はこの値を終了として考慮でき、Pod に具体的にスコープを指定した ResourceQuota オブジェクトを使用できます。
• configmaps を使用して、タスク実行、パイプライン実行、タスク、およびパイプラインのメトリックタグまたはラベルタイプを削除できます。さらに、ヒストグラム、ゲージ、最終値など、測定期間に、さまざまな種類のメトリックを設定できます。
• Tekton は Min、Max、Default および DefaultRequest フィールドを考慮して LimitRange オブジェクトを完全にサポートするため、一貫性をもたせて Pod への要求および制限を定義できます。

• 以下のアルファ機能が導入されました。

  • パイプライン実行は、以前の動作のように、すべてのタスク実行を直接停止するのではなく、finally タスクの実行後に停止できるようになりました。今回の更新により、以下の spec.status 値が追加されました。

    • StoppedRunFinal は、完了後、現在実行中のタスクを停止し、finally タスクを実行します。
    • CancelledRun は、実行中のタスクをすぐにキャンセルしてから、finally タスクを実行します。

    • Cancelled は、PipelineRunCancelled ステータスで提供される以前の動作を保持します。

      注記

      非推奨となった PipelineRunCancelled ステータスは v1 バージョンで削除され、Cancelled ステータスに置き換えられます。

  • oc debug コマンドを使用して、タスク実行をデバッグモードに配置できるようになりました。これにより、実行を一時停止し、Pod で特定の手順を検査できるようになりました。
  • ステップの onError フィールドを continue に設定すると、ステップの終了コードが記録され、後続のステップに渡されます。ただし、タスク実行は失敗しないので、タスクの残りのステップの実行は継続されます。既存の動作を維持するには、onError フィールドの値を stopAndFail に設定します。
  • タスクは、実際に使用されているよりも多くのパラメーターを受け入れるようになりました。アルファ機能フラグを有効にすると、パラメーターは暗黙的にインライン仕様に伝播できます。たとえば、インラインのタスクは、タスクの各パラメーターを明示的に定義せずに、親パイプライン実行のパラメーターにアクセスできます。
  • アルファ機能のフラグを有効にすると、when 式の条件が、直接関連付けられたタスクにのみ適用され、タスクに依存することはありません。When 式を関連タスクとその依存に適用するには、式を依存タスクごとに個別に関連付ける必要があります。今後、これが Tekton の新規 API バージョンの When 式のデフォルト動作になることに注意してください。今回の更新が優先され、既存のデフォルト動作は非推奨になりました。

• 現在のリリースでは、nodeSelector および tolerations の値を TektonConfig カスタムリソース (CR) に指定することで、ノードの選択を設定できます。Operator はこれらの値を、作成するすべてのデプロイメントに追加します。

  • Operator のコントローラーおよび Webhook デプロイメントのノード選択を設定するには、Operator のインストール後に Subscription CR の仕様で config.nodeSelector および config.tolerations フィールドを編集します。
  • OpenShift Pipelines の残りのコントロールプレーン Pod をインフラストラクチャーノードにデプロイするには、nodeSelector および tolerations フィールドで TektonConfig CR を更新します。その後、変更は Operator で作成されるすべての Pod に適用されます。