1.3. Red Hat OpenShift Pipelines 一般提供 1.16 のリリースノート

この更新により、Red Hat OpenShift Pipelines General Availability (GA) 1.16 が OpenShift Container Platform 4.15 以降のバージョンで利用できるようになります。

1.3.1. 新機能

修正と安定性の向上に加えて、次のセクションでは Red Hat OpenShift Pipelines 1.16 の新機能について説明します。

1.3.1.1. Pipelines

この更新により、パイプラインコントローラーの再同期の期間を設定できるようになります。再同期の期間ごとに、コントローラーはイベントに関係なく、すべてのパイプライン実行とタスク実行を調整します。デフォルトの再同期期間は 10 時間です。パイプライン実行とタスク実行の数が多い場合、10 時間ごとに完全な調整を行うと、リソースが過剰に消費される可能性があります。この場合、より長い再同期期間を設定できます。
再同期期間を 24 時間に設定する例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      deployments:
        tekton-pipelines-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-pipelines-controller
                  args:
                    - "-resync-period=24h"
# ...
```
この更新により、パイプラインを定義するときに、タスクを 続行する ための onError パラメーターを設定できるようになりました。この設定を行うと、パイプラインの実行時にタスクが失敗すると、パイプラインはエラーをログに記録し、次のタスクに進みます。デフォルトでは、パイプライン内のタスクが失敗するとパイプラインは失敗します。
onError パラメーターの設定例。task-that-fails タスクが失敗すると、next-task が実行されます。
```
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: example-onerror-pipeline
spec:
  tasks:
  - name: task-that-fails
    onError: continue
    taskSpec:
      steps:
      - image: alpine
        name: exit-with-1
        script: |
          exit 1
  - name: next-task
# ...
```
この更新により、タスクが失敗した場合、finally タスクは status パラメーターに加えて reason パラメーターにアクセスして、失敗が許可されたかどうかを区別できるようになります。$(tasks.<task_name>.reason) を使用して reason パラメーターにアクセスできます。失敗が許可された場合、reason は FailureIgnored に設定されます。失敗が許可されない場合、reason は Failed に設定されます。この追加情報を使用して、チェックが失敗したことを識別できますが、失敗は無視できます。
この更新では、結果をステップごとに 4 KB、タスク実行ごとに 12 KB のサイズに制限するデフォルト設定の代わりに、サイドカーログを通じてより大きな結果がサポートされるようになりました。サイドカーログを使用してより大きな結果を有効にするには、TektonConfig CR で pipeline.options.configMaps.feature-flags.data.results-from 仕様を sidecar-logs に設定します。
サイドカーログを使用してより大きな結果を有効にする例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      configMaps:
        feature-flags:
          data:
            results-from: "sidecar-logs"
# ...
```

この更新前は、パラメーターの伝播は PipelineRun および TaskRun リソースでは許可されていましたが、Pipeline リソースでは許可されていませんでした。この更新により、Pipeline リソース内の params をインラインパイプライン tasks とそのインライン steps に伝播できるようになります。PipelineTask や StepAction などのリソースが参照されるたびに、パラメーターを明示的に渡す必要があります。

パイプライン内で params を使用する例

apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-propagated-params
spec:
  params:
    - name: HELLO
      default: "Hello World!"
    - name: BYE
      default: "Bye World!"
  tasks:
    - name: echo-hello
      taskSpec:
        steps:
          - name: echo
            image: ubuntu
            script: |
              #!/usr/bin/env bash
              echo "$(params.HELLO)"
    - name: echo-bye
      taskSpec:
        steps:
          - name: echo-action
            ref:
              name: step-action-echo
            params:
              - name: msg
                value: "$(params.BYE)"
# ...

この更新により、タスク実行またはパイプライン実行定義を使用して、タスク内のステップとサイドカーのコンピュートリソースを設定できるようになります。

リソースを設定するためのタスクの例

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: side-step
spec:
  steps:
    - name: test
      image: docker.io//alpine:latest
  sidecars:
    - name: side
      image: docker.io/linuxcontainers/alpine:latest
# ...

リソースを設定する TaskRun 定義の例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: test-sidestep
spec:
  taskRef:
    name: side-step
  stepSpecs:
    - name: test
      computeResources:
        requests:
          memory: 1Gi
  sidecarSpecs:
    - name: side
      computeResources:
        requests:
          cpu: 100m
        limits:
          cpu: 500m
# ...

1.3.1.2. Operator

この更新により、OpenShift Pipelines には、Git リポジトリーをクローンするステップの git-clone StepAction 定義が含まれるようになりました。HTTP リゾルバーを使用してこの定義を参照します。定義の URL は https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml です。StepAction 定義は、openshift-pipelines namespace にもインストールされます。ただし、クラスターリゾルバーは StepAction 定義をサポートしません。
タスクでの git-clone ステップアクションの使用例
```
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: clone-repo-anon
spec:
  params:
  - name: url
    description: The URL of the Git repository to clone
  workspaces:
  - name: output
    description: The git repo will be cloned onto the volume backing this Workspace.
  steps:
  - name: clone-repo-anon-step
    ref:
      resolver: http
      params:
      - name: url
        value: https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml
    params:
    - name: URL
      value: $(params.url)
    - name: OUTPUT_PATH
      value: $(workspaces.output.path)
# ...
```
この更新により、openshift-pipelines namespace には、標準タスクとともにバージョン管理されたタスクが含まれるようになりました。たとえば、buildah 標準タスクと buildah-1-16-0 バージョンタスクがあります。標準タスクは後続のリリースで更新される可能性がありますが、バージョン管理されたタスクは、エラーの修正を除いて、指定されたバージョンとまったく同じままです。
この更新により、TektonConfig CR を使用して、OpenShift Pipelines のいくつかのコンポーネントの Webhook の FailurePolicy、TimeoutSeconds、および SideEffects オプションを設定できるようになりました。次の例は、pipeline コンポーネントの設定を示しています。triggers、pipelinesAsCode、および hub コンポーネントの Webhook にも同様の設定を使用できます。
pipeline コンポーネントの Webhook オプションの設定例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      webhookConfigurationOptions:
        validation.webhook.pipeline.tekton.dev:
          failurePolicy: Fail
          timeoutSeconds: 20
          sideEffects: None
        webhook.pipeline.tekton.dev:
          failurePolicy: Fail
          timeoutSeconds: 20
          sideEffects: None
# ...
```

1.3.1.3. トリガー

この更新により、トリガーコントローラー、Webhook、Core Interceptor、およびイベントリスナーの readOnlyRootFilesystem パラメーターがデフォルトで true に設定され、セキュリティーが向上し、セキュリティースキャナーによるフラグ付けが回避されるようになりました。
この更新により、コンテナー内で root 以外のユーザーとしてイベントリスナーを実行するように OpenShift Pipelines トリガーを設定できるようになりました。このオプションを設定するには、次の例に示すように、TektonConfig CR でパラメーターを設定します。
root 以外のユーザーとして実行するトリガーイベントリスナーの設定例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  trigger:
    options:
      disabled: false
      configMaps:
        config-defaults-triggers:
          data:
            default-run-as-non-root: "true"
            default-run-as-user: "65532"
            default-run-as-group: "65532"
            default-fs-group: "65532"
# ...
```
オプションで、default-run-as-user および default-run-as-group パラメーターの値を設定して、コンテナー内でイベントリスナーを実行するための数値のユーザー ID とグループ ID を設定できます。OpenShift Pipelines は、イベントリスナーの Pod セキュリティーコンテキストとコンテナーセキュリティーコンテキストにこれらの値を設定します。空の値を使用すると、デフォルトのユーザー ID とグループ ID 65532 が使用されます。
default-fs-group パラメーターを設定して、Pod セキュリティーコンテキストの fsGroup 値を定義することもできます。これは、コンテナープロセスがファイルシステムに使用するグループ ID です。空の値を使用すると、デフォルトのグループ ID 65532 が使用されます。
この更新により、トリガーの EventListener Pod テンプレートに securityContext 設定が含まれるようになりました。これらの設定では、el-security-context フラグが true に設定されている場合に、seccompProfile、runAsUser、runAsGroup、および fsGroup パラメーターを設定できます。

1.3.1.4. Web コンソール

このリリースより前は、Web コンソールを使用する場合、OpenShift Pipelines が作成したログのタイムスタンプを表示できませんでした。この更新により、Web コンソールにすべての OpenShift Pipelines ログのタイムスタンプが含まれるようになりました。
この更新により、Web コンソールのパイプライン実行ページとタスク実行 リスト ページに、k8s や TektonResults API などのデータソースのフィルターが追加されました。
この更新前は、開発者 パースペクティブで Web コンソールを使用する場合、パイプライン実行のタイムアウトを指定できませんでした。この更新により、Web コンソールの 開発者 パースペクティブでパイプラインの実行を開始するときにタイムアウトを設定できるようになりました。
この更新前は、Overview パイプラインダッシュボードは、Tekton Results が有効になっている場合にのみ表示されていました。すべての統計は Results API からのみ取得されました。この更新により、Tekton Results が有効かどうかに関係なく、Overview パイプラインダッシュボードが利用できるようになります。Tekton Results が無効になっている場合は、ダッシュボードを使用してクラスター内のオブジェクトの統計情報を表示できます。
この更新により、Web コンソールに表示されるサンプルパイプラインは OpenShift Pipelines API の v1 バージョンを使用します。

1.3.1.5. CLI

この更新では、tkn customrun delete <custom_run_names> コマンドを使用して、1 つ以上のカスタム実行を削除できます。
この更新により、-o YAML フラグを指定して tkn <resource> list コマンドを実行すると、リストされたリソースが --- 区切り文字で区切られるようになり、出力が読みやすくなります。

1.3.1.6. Pipelines as Code

この更新により、同じ名前の PipelineRun 定義を 2 つ作成すると、Pipelines as Code はエラーをログに記録し、どちらのパイプライン実行も実行されなくなります。
この更新により、Pipelines as Code の pipelines_as_code_pipelinerun_count メトリクスを使用して、リポジトリーまたは namespace 別に PipelineRun 数をフィルタリングできるようになりました。
この更新により、セキュリティーを強化し、セキュリティースキャナーによるフラグ付けを回避するために、Pipelines as Code コントローラー、Webhook、ウォッチャーの readOnlyRootFilesystem セキュリティーコンテキストがデフォルトで true に設定されるようになりました。

1.3.1.7. Tekton Chains

この更新により、Tekton Chains で docdb ストレージを使用する場合、TektonConfig CR で storage.docdb.mongo-server-url 設定として MONGO_SERVER_URL 値を直接設定できるようになりました。または、シークレットを使用してこの値を提供し、storage.docdb.mongo-server-url-dir 設定を MONGO_SERVER_URL ファイルが配置されているディレクトリーに設定することもできます。

MONGO_SERVER_URL 値を使用してシークレットを作成する例

$ oc create secret generic mongo-url -n tekton-chains \ #
  --from-file=MONGO_SERVER_URL=/home/user/MONGO_SERVER_URL

シークレットを使用して MONGO_SERVER_URL 値を設定する例

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    storage.docdb.mongo-server-url-dir: /tmp/mongo-url
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-chains-controller
                  volumeMounts:
                  - mountPath: /tmp/mongo-url
                    name: mongo-url
                volumes:
                -  name: mongo-url
                   secret:
                    secretName: mongo-url
# ...

この更新により、Tekton Chains で KMS 署名を使用する場合、設定で KMS 認証トークン値を直接指定する代わりに、signers.kms.auth.token-path 設定を使用してトークン値をシークレットとして指定できるようになりました。

KMS トークンシークレットを作成するには、次のコマンドを入力します。

$ oc create secret generic <secret_name> -n tekton-chains \
  --from-file=KMS_AUTH_TOKEN=/home/user/KMS_AUTH_TOKEN 1

1: <secret_name> は、任意の名前に置き換えます。次の例では、kms-secrets という KMS シークレットを使用します。

kms-secrets というシークレットを使用した KMS トークン値の設定例

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    signers.kms.auth.token-path: /etc/kms-secrets/KMS_AUTH_TOKEN
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-chains-controller
                  volumeMounts:
                  - mountPath: /etc/kms-secrets
                    name: kms-secrets
                volumes:
                -  name: kms-secrets
                   secret:
                    secretName: kms-secrets
# ...

この更新により、Tekton Chains コントローラーへの引数として namespace のリストを設定できるようになりました。このリストを指定すると、Tekton Chains は指定された nemespace 内でのみパイプラインの実行とタスクの実行を監視します。このリストを指定しない場合、Tekton Chains はすべての namespace でのパイプラインの実行とタスクの実行を監視します。
dev および test namespace のみを監視する設定例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - args:
                  - --namespace=dev, test
                  name: tekton-chains-controller
# ...
```

1.3.1.8. Tekton Results

この更新前は、Tekton Results は v1beta1 API 形式を使用して TaskRun および PipelineRun オブジェクトレコードを保存していました。この更新により、Tekton Results は v1 API 形式を使用して TaskRun および PipelineRun オブジェクトレコードを保存します。
この更新により、Tekton Results は既存のレコードを v1 API 形式に自動的に変換できるようになります。このような変換を有効にするには、次の例に示すように、TektonResult CR でパラメーターを設定します。
既存のレコードを v1 API 形式に変換する Tekton Results の設定例
```
  apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
    deployments:
      tekton-results-api:
        spec:
          template:
            spec:
              containers:
                - name: api
                  env:
                    - name: CONVERTER_ENABLE
                      value: "true"
                    - name: CONVERTER_DB_LIMIT
                      value: "256" 1
# ...
```
1
CONVERTER_DB_LIMIT 変数で、単一のトランザクションで同時に変換するレコードの数を設定します。
この更新により、Tekton Results はサードパーティーのログ記録 API から転送されたログの取得をサポートするようになりました。logs_api を true に、logs_type を Loki に設定して、TektonResult CR を通じてログ記録 API を有効にできます。
この更新により、Tekton Results データベースの自動プルーニングを設定できるようになります。レコードを保存する日数を指定できます。古いレコードを削除するプルーナージョブを実行するスケジュールを指定することもできます。これらのパラメーターを設定するには、次の例に示すように TektonResult CR を編集します。
Tekton 結果データベースの自動プルーニングを設定する例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
    configMaps:
      config-results-retention-policy:
        data:
          runAt: "3 5 * * 0" 1
          maxRetention: "30" 2
# ...
```
1
データベースでプルーニングジョブを実行するタイミングを cron 形式で指定します。この例では、毎週日曜日の午前 5 時 3 分にジョブを実行します。
2
データベースにデータを保持する日数を指定します。この例では、データを 30 日間保持します。
この更新により、パイプラインとタスクのイベントログを保存するように Tekton Results を設定できるようになります。イベントログの保存を有効にするには、次の例に示すように TektonResult CR を編集します。
Tekton 結果データベースの自動プルーニングを設定する例
```
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
     deployments:
        tekton-results-watcher:
          spec:
            template:
              spec:
                containers:
                  - name: watcher
                    args:
                      - "--store_event=true"
# ...
```

この更新により、Tekton Results を設定して、OpenShift Container Platform Cluster Log Forwarder を使用して、すべてのログデータをストレージボリュームに直接配置するのではなく、LokiStack インスタンスに保存できるようになりました。このオプションを使用すると、パイプライン実行とタスク実行の頻度を増やすようにスケーリングできます。

Tekton Results を設定して、OpenShift Container Platform Cluster Log Forwarder を使用してすべてのログデータを LokiStack インスタンスに保存するには、Loki Operator を使用してクラスターに LokiStack をデプロイし、OpenShift ロギング Operator もインストールする必要があります。次に、以下の YAML マニフェストのいずれかを使用して ClusterLogForwarder CR を openshift-logging namespace に作成する必要があります。

OpenShift Logging バージョン 6 をインストールしている場合の ClusterLogForwarder CR の YAML マニフェスト

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  inputs:
  - application:
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: tekton-pipelines
    name: only-tekton
    type: application
  managementState: Managed
  outputs:
  - lokiStack:
      labelKeys:
        application:
          ignoreGlobal: true
          labelKeys:
          - log_type
          - kubernetes.namespace_name
          - openshift_cluster_id
      authentication:
        token:
          from: serviceAccount
      target:
        name: logging-loki
        namespace: openshift-logging
    name: default-lokistack
    tls:
      ca:
        configMapName: openshift-service-ca.crt
        key: service-ca.crt
    type: lokiStack
  pipelines:
  - inputRefs:
    - only-tekton
    name: default-logstore
    outputRefs:
    - default-lokistack
  serviceAccount:
    name: collector
# ...

OpenShift Logging バージョン 5 をインストールしている場合の ClusterLogForwarder CR の YAML マニフェスト

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
  - name: only-tekton
    application:
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: tekton-pipelines
  pipelines:
    - name: enable-default-log-store
      inputRefs: [ only-tekton ]
      outputRefs: [ default ]
# ...

最後に、openshift-pipelines namespace の TektonResult CR で、次の追加パラメーターを設定します。

loki_stack_name: LokiStack CR の名前。通常は logging-loki です。
loki_stack_namespace : LokiStack がデプロイされている namespace の名前。通常は openshift-logging です。

TektonResult CR で LokiStack ログ転送を設定する例

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  targetNamespace: tekton-pipelines
# ...
  loki_stack_name: logging-loki
  loki_stack_namespace: openshift-logging
# ...

1.3.2. 互換性を失わせる変更点

この更新により、受信したイベントをカウントするパイプライントリガーの EventListener オブジェクトのメトリクス名が eventlistener_event_count から eventlistener_event_received_count に変更されます。

1.3.3. 既知の問題

OpenShift Container Platform バージョン 4.16 以降を使用している場合、jib-maven ClusterTask は機能しません。

1.3.4. 修正された問題

この更新前は、TektonHub CR を削除して Tekton Hub をアンインストールしても、hub-db-migration ジョブの Pod は削除されませんでした。この更新により、Tekton Hub をアンインストールすると Pod も削除されます。
この更新前は、Tekton Results を使用してパイプラインとタスクからの Pod ログを保存すると、ログを保存する操作が失敗することがあります。ログには、canceled context のエラーで失敗した UpdateLog アクションが含まれます。この更新により、操作は正常に完了します。
この更新前は、パラメーター値をパイプラインまたはタスクに渡し、その値として完全な参照形式と短い参照形式の両方が指定された複数の変数 (例: $(tasks.task-name.results.variable1) + $(variable2)) が含まれていた場合、OpenShift Pipelines は値を正しく解釈しませんでした。パイプラインの実行またはタスクの実行が停止し、パイプラインコントローラーがクラッシュする可能性があります。この更新により、OpenShift Pipelines は値を正しく解釈し、パイプラインの実行またはタスクの実行が完了します。
この更新前は、タスク実行に同じ名前の複数のタスクが含まれている場合に、Tekton Chains は正しいアテステーションを生成できませんでした。たとえば、タスクのマトリックスを使用する場合、最初のイメージに対してアテステーションが生成されます。この更新により、Tekton Chains はタスク実行内のすべてのタスクのアテステーションを生成し、完全なカバレッジを保証します。
この更新前は、OpenShift Pipelines インストール namespace で定義された skopeo-copy タスクを使用し、その VERBOSE パラメーターを false に設定すると、タスクは失敗していました。この更新により、タスクは正常に完了します。
この更新前は、Pipelines as Code を使用する場合、すべての Repository CR にデフォルト設定を提供する、openshift-pipelines または pipelines-as-code にある as-code という名前の名前のグローバル Repository CR で concurrency_limit 仕様を設定すると、Pipelines as Code ウォッチャーがクラッシュしていました。この更新により、Pipelines as Code ウォッチャーはこの設定で正しく動作するようになりました。
この更新前は、OpenShift Pipelines のすべてのタスクには、以前のバージョンの OpenShift Pipelines で使用可能だった同じ名前のクラスタータスクと比較して追加のステップが含まれていました。この追加ステップにより、クラスターの負荷が増加しました。この更新により、タスクには最初のステップに統合されたため、追加のステップは含まれなくなりました。
この更新前は、OpenShift Pipelines インストール namespace で定義された s2i-* タスクの 1 つを使用し、その CONTEXT パラメーターを設定すると、タスクによりパラメーターが正しく解釈せず、タスクが失敗していました。この更新により、タスクは CONTEXT パラメーターを正しく解釈し、正常に完了します。
この更新前は、Tekton Chains の全体的な来歴メタデータ、URI、および Digest 値が不完全でした。値にはリモート Pipeline および Task リソースの情報のみが含まれていましたが、リモート StepAction リソースの情報が欠落していました。この更新により、リモート StepAction リソースの来歴がタスク実行ステータスに記録され、in-toto 来歴に挿入され、完全な in-toto 来歴メタデータが生成されます。
この更新前は、リソースの作成後に変更できないはずの PipelineRun および TaskRun リソースの spec フィールドの一部のパラメーターを変更できました。この更新により、パイプライン実行とタスク実行が作成された後に、status フィールドや statusMessage フィールドなど、許可されたフィールドのみを変更できるようになります。
この更新前は、ステップアクションパラメーターが array 型であるが、タスクで string 値が渡された場合、パラメーターの型が一致していないことを示すエラーは発生せず、代わりにデフォルトのパラメーター値が使用されていました。この更新では、矛盾した値を示す以下のエラーが追加されます。invalid parameter substitution: %s.Please check the types of the default value and the passed value.
この更新前は、ログがウォッチャーを介してストリーミングされたときに、タスク実行とパイプライン実行が外部プルーナーによって削除されていました。この更新では、TaskRun および PipelineRun オブジェクトの Tekton Results にファイナライザーが追加され、実行が保存され、削除されないようになります。実行は、記録用に、または期限が過ぎるまで保存されます。期限は、完了時間に store_deadline 時間を加算して計算されます。ウォッチャーまたはプルーナーからのレガシーログストリーミングが有効になっている場合、ファイナライザーは削除を防止しません。
この更新前は、Web コンソールは、Tekton Results に保存されている TaskRun および PipelineRun オブジェクトレコードを表示するために v1beta1 API 形式をサポートしていました。この更新により、コンソールは、Tekton Results に保存されている TaskRun および PipelineRun オブジェクトレコードを表示するための v1 API 形式をサポートするようになりました。
この更新前は、Pipelines as Code を使用する場合、異なる PipelineRun 定義で、タスク名が同じで、バージョンが異なるものを使用すると (たとえば、Tekton Hub からタスクを取得する場合)、Pipelines as Code がすべてのパイプライン実行に同じタスクバージョンを使用するため、間違ったバージョンがトリガーされることがありました。この更新により、Pipelines as Code は参照されたタスクの正しいバージョンをトリガーします。
この更新前は、リゾルバーを使用してリモートパイプラインまたはタスクを参照すると、一時的な通信エラーが発生し、それらのリモート参照の取得がすぐに失敗していました。この更新により、リゾルバーは取得を再度キューに入れ、最終的に取得を再試行します。
この更新前は、Tekton Results でパイプライン実行とタスク実行のログ情報を保存するときに、使用するメモリーの量が増える可能性がありました。この更新によりメモリーリークが修正され、Tekton Results は通常の量のメモリーを使用します。
この更新前は、Pipelines as Code を使用しており、.tekton ディレクトリーに、イベントでトリガーされた PipelineRun 定義から参照されていないパイプラインが含まれていた場合に、Pipelines as Code は、実行されていなくても、そのパイプラインに必要なすべてのタスクを取得しようとします。この更新により、Pipelines as Code は、現在のイベントによってトリガーされたパイプライン実行で参照されていないパイプラインを解決しようとしなくなりました。

1.3.5. Red Hat OpenShift Pipelines 一般提供 1.16.1 のリリースノート

この更新により、Red Hat OpenShift Pipelines General Availability (GA) 1.16.1 が OpenShift Container Platform 4.15 以降のバージョンで利用できるようになります。

1.3.5.1. 修正された問題

この更新前は、Web コンソールの Pipelines overview ページで、すべての名前空間へのアクセス権を持たないユーザーは、Projects リストで All を選択できました。一部の namespace の統計情報がユーザーに提供されなかったため、コンソールにはその選択に対して誤った情報が表示されました。この更新により、すべての namespace へのアクセス権のないユーザーは、Projects リストで All を選択できなくなります。
この更新前は、Web コンソールを使用して、array のパラメーターを定義したパイプラインまたはタスクを開始しようとすると、このパラメーターの値を入力するとエラーが発生し、パイプラインまたはタスクを開始できませんでした。この更新により、Web コンソールを使用して、array 型のパラメーターを定義するパイプラインまたはタスクを開始できるようになり、このパラメーターの値の入力が正常に機能するようになりました。
この更新前は、Bitbucket Git リポジトリーで Pipelines as Code を使用すると、Pipelines as Code コントローラーがクラッシュすることがあり、panic: runtime error: invalid memory address or nil pointer dereference メッセージがログに記録されていました。この更新により、Pipelines as Code コントローラーがクラッシュしなくなりました。
この更新の前は、Tekton Results を使用すると、tekton-results-watcher Pod がクラッシュすることがあり、panic:runtime error:invalid memory address or nil point dereference という メッセージがログに記録されていました。この更新により、tekton-results-watcher Pod がクラッシュしなくなりました。
この更新前は、Tekton Results を使用するときに、Tekton Results で認証を有効にすると、Web コンソールが Tekton Results API に認証トークンを渡すことができなかったため、Web コンソールで Tekton Results の情報を表示できませんでした。この更新により、認証が有効になっている場合に、Web コンソールで Tekton Results の情報を表示できるようになります。
この更新前は、Web コンソールで Tekton Results の情報を表示するときに、ページの最後までスクロールすると、コンソールは次のレコードセットを取得できず、一部の情報が表示されませんでした。この更新により、ページの最後までスクロールすると、Tekton Results からのレコードが正しく読み込まれ、すべての情報が Web コンソールに正しく表示されます。

1.3.6. Red Hat OpenShift Pipelines General Availability 1.17 のリリースノート

この更新により、Red Hat OpenShift Pipelines General Availability (GA) 1.17 が OpenShift Container Platform 4.15 以降のバージョンで利用できるようになります。

1.3.6.1. 修正された問題

この更新前は、OpenShift Pipelines 1.16 では、PipelineRun オブジェクトにパッチを適用し、パイプライン実行の最初のタスク実行が完了すると、spec.status パラメーターを Cancelled に設定することでパイプラインの実行をキャンセルできませんでした。代わりに、PipelineRun was cancelled というエラーメッセージがログに記録されましたが、TaskRun や Runs をキャンセルしようとしたエラー がありました。今回の更新により、パイプラインの実行が正常にキャンセルされるようになりました。