[RHDEVDOCS-6753] Add TektonConfig RN configuration to base

install_config/customizing-configurations-in-the-tektonconfig-cr.adoc

@@ -13,9 +13,15 @@ In {pipelines-title}, you can customize the following configurations by using th
 * Changing the default service account
 * Disabling the service monitor
 * Configuring pipeline resolvers
+* Configuring pipeline resolver timeouts
+* Configuring resolver caching
 * Disabling pipeline templates
 * Disabling the integration of {tekton-hub}
 * Disabling the automatic creation of RBAC resources
+* Customizing {tekton-results} deployments
+* Configuring fine-grained retention policies for {tekton-results}
+* Generating cosign key pairs for {tekton-chains}
+* Configuring automatic cancellation for {pac}
 * Pruning of task runs and pipeline runs
 
 [id="prerequisites_customizing-configurations-in-the-tektonconfig-cr"]
@@ -41,6 +47,10 @@ include::modules/op-disabling-the-service-monitor.adoc[leveloffset=+1]
 
 include::modules/op-configuring-pipeline-resolvers.adoc[leveloffset=+1]
 
+include::modules/op-configuring-pipeline-resolver-timeouts.adoc[leveloffset=+1]
+
+include::modules/op-configuring-resolver-caching.adoc[leveloffset=+1]
+
 include::modules/op-disabling-pipeline-templates.adoc[leveloffset=+1]
 
 include::modules/op-disabling-pipeline-triggers.adoc[leveloffset=+1]
@@ -58,6 +68,14 @@ include::modules/op-disabling-inline-spec.adoc[leveloffset=+1]
 
 include::modules/op-configuration-rbac-trusted-ca-flags.adoc[leveloffset=+1]
 
+include::modules/op-customizing-tekton-results-deployments.adoc[leveloffset=+1]
+
+include::modules/op-configuring-tekton-results-retention-policies.adoc[leveloffset=+1]
+
+include::modules/op-generating-cosign-key-pairs.adoc[leveloffset=+1]
+
+include::modules/op-configuring-pac-cancel-in-progress.adoc[leveloffset=+1]
+
 include::modules/op-automatic-pruning-taskrun-pipelinerun.adoc[leveloffset=+1]
 
 include::modules/op-default-pruner-configuration.adoc[leveloffset=+2]

modules/op-configuring-pac-cancel-in-progress.adoc

@@ -0,0 +1,90 @@
+// Module included in the following assemblies:
+//
+// * install_config/customizing-configurations-in-the-tektonconfig-cr.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="op-configuring-pac-cancel-in-progress_{context}"]
+= Configuring automatic cancellation for Pipelines as Code
+
+[role="_abstract"]
+You can configure {pac} to automatically cancel in-progress pipeline runs when new commits are pushed to a pull request or branch. This helps conserve resources and ensures that only the most recent code changes are being tested.
+
+.Prerequisites
+
+* You have access to an {OCP} cluster with cluster administrator permissions.
+* You have installed the {pipelines-title} Operator.
+* {pac} is enabled in your {pipelines-shortname} installation.
+
+.Procedure
+
+. In your `TektonConfig` custom resource, configure cancel-in-progress settings in the `spec.platforms.openshift.pipelinesAsCode.settings` section:
++
+[source,yaml]
+----
+apiVersion: operator.tekton.dev/v1alpha1
+kind: TektonConfig
+metadata:
+  name: config
+spec:
+  platforms:
+    openshift:
+      pipelinesAsCode:
+        enable: true
+        settings:
+          enable-cancel-in-progress-on-pull-requests: "true"
+          enable-cancel-in-progress-on-push: "true"
+# ...
+----
++
+where:
++
+`enable-cancel-in-progress-on-pull-requests`:: Specifies whether to automatically cancel in-progress pipeline runs when new commits are pushed to a pull request. Set to `true` to enable automatic cancellation. The default value is `false`.
+`enable-cancel-in-progress-on-push`:: Specifies whether to automatically cancel in-progress pipeline runs when new commits are pushed to a branch. Set to `true` to enable automatic cancellation. The default value is `false`.
+
+. Save the changes and exit the editor.
+
+.Verification
+
+. Verify that the {pac} configuration is updated:
++
+[source,terminal]
+----
+$ oc get configmap pipelines-as-code -n openshift-pipelines -o yaml
+----
++
+[source,yaml]
+----
+apiVersion: v1
+data:
+  enable-cancel-in-progress-on-pull-requests: "true"
+  enable-cancel-in-progress-on-push: "true"
+kind: ConfigMap
+# ...
+----
+
+. Test the configuration by pushing multiple commits to a pull request or branch:
+.. Create a pull request or push to a branch that triggers a pipeline run.
+.. Before the pipeline run completes, push another commit to the same pull request or branch.
+.. Verify that the first pipeline run is automatically canceled:
++
+[source,terminal]
+----
+$ oc get pipelinerun -n <namespace> --sort-by=.metadata.creationTimestamp
+----
++
+[source,terminal]
+----
+NAME                STATUS      AGE
+pipeline-run-abc    Cancelled   5m
+pipeline-run-xyz    Running     1m
+----
+
+[IMPORTANT]
+====
+Individual `PipelineRun` resources can override these global settings by using the `pipelinesascode.tekton.dev/cancel-in-progress` annotation. If this annotation is present on a `PipelineRun`, it takes precedence over the global `TektonConfig` settings.
+====
+
+[NOTE]
+====
+When cancel-in-progress is enabled, older pipeline runs are canceled as soon as a new commit triggers a new pipeline run. This helps prevent wasting resources on testing outdated code but means that you might not have complete test results for every commit in a pull request.
+====

modules/op-configuring-pipeline-resolver-timeouts.adoc

@@ -0,0 +1,79 @@
+// Module included in the following assemblies:
+//
+// * install_config/customizing-configurations-in-the-tektonconfig-cr.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="op-configuring-pipeline-resolver-timeouts_{context}"]
+= Configuring pipeline resolver timeouts
+
+[role="_abstract"]
+You can configure resolution timeout settings for pipeline resolvers to gain greater flexibility and control when running a pipeline. This enables you to set a global maximum timeout for resolution requests and configure resolver-specific timeouts.
+
+.Prerequisites
+
+* You have access to an {OCP} cluster with cluster administrator permissions.
+* You have installed the {pipelines-shortname} Operator.
+
+.Procedure
+
+. In your `TektonConfig` custom resource, add or update the timeout settings in the `spec.pipeline.options.configMaps` section:
++
+[source,yaml]
+----
+apiVersion: operator.tekton.dev/v1alpha1
+kind: TektonConfig
+metadata:
+  name: config
+spec:
+  pipeline:
+    options:
+      configMaps:
+        config-defaults:
+          data:
+            default-maximum-resolution-timeout: 5m
+        bundleresolver-config:
+          data:
+            fetch-timeout: 1m
+# ...
+----
++
+where:
++
+`default-maximum-resolution-timeout`:: Specifies the global maximum timeout for resolution requests. The default value is `1m`.
+`fetch-timeout`:: Specifies the timeout for bundle resolution requests.
+
+. Save the changes and exit the editor.
+
+.Verification
+
+. Verify that the timeout settings are applied:
++
+[source,terminal]
+----
+$ oc get configmap config-defaults -n openshift-pipelines -o yaml
+----
++
+[source,terminal]
+----
+apiVersion: v1
+data:
+  default-maximum-resolution-timeout: 5m
+kind: ConfigMap
+# ...
+----
+
+. Verify the bundle resolver configuration:
++
+[source,terminal]
+----
+$ oc get configmap bundleresolver-config -n openshift-pipelines -o yaml
+----
++
+[source,terminal]
+----
+apiVersion: v1
+data:
+  fetch-timeout: 1m
+kind: ConfigMap
+# ...
+----

modules/op-configuring-resolver-caching.adoc

@@ -0,0 +1,133 @@
+// Module included in the following assemblies:
+//
+// * install_config/customizing-configurations-in-the-tektonconfig-cr.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="op-configuring-resolver-caching_{context}"]
+= Configuring resolver caching
+
+[role="_abstract"]
+You can configure resolver caching for bundle, Git, and cluster resolvers to reduce redundant fetches, minimize external API calls, and improve pipeline execution reliability. Caching is particularly useful when external services impose rate limits or are temporarily unavailable.
+
+.Prerequisites
+
+* You have access to an {OCP} cluster with cluster administrator permissions.
+* You have installed the {pipelines-title} Operator.
+
+.Procedure
+
+. In your `TektonConfig` custom resource, configure global cache settings in the `spec.pipeline.options.configMaps.resolver-cache-config` section:
++
+[source,yaml]
+----
+apiVersion: operator.tekton.dev/v1alpha1
+kind: TektonConfig
+metadata:
+  name: config
+spec:
+  pipeline:
+    options:
+      configMaps:
+        resolver-cache-config:
+          data:
+            max-size: "1000"
+            ttl: "5m"
+# ...
+----
++
+where:
++
+`max-size`:: Specifies the maximum number of cached entries. The default value is `"1000"`.
+`ttl`:: Specifies the time to live (TTL) of cache entries. The default value is `"5m"`.
+
+. Optional: Configure the default caching mode for specific resolvers by adding the `cache` parameter to resolver-specific config maps:
++
+[source,yaml]
+----
+apiVersion: operator.tekton.dev/v1alpha1
+kind: TektonConfig
+metadata:
+  name: config
+spec:
+  pipeline:
+    bundleresolver-config:
+      cache: "auto"
+    git-resolver-config:
+      cache: "auto"
+    cluster-resolver-config:
+      cache: "auto"
+# ...
+----
++
+where:
++
+`cache`:: Specifies the caching mode for the resolver. Valid values are:
++
+--
+* `auto`: Cache only immutable references, such as specific commit SHAs or image digests (default)
+* `always`: Cache all resolved resources regardless of mutability
+* `never`: Disable caching entirely
+--
+
+. Optional: Override the default caching mode for individual pipeline runs or task runs by adding the `cache` parameter to the run specification:
++
+[source,yaml]
+----
+apiVersion: tekton.dev/v1
+kind: PipelineRun
+metadata:
+  name: example-pipelinerun
+spec:
+  pipelineRef:
+    resolver: git
+    params:
+      - name: url
+        value: https://github.com/example/repo.git
+      - name: revision
+        value: main
+      - name: pathInRepo
+        value: pipeline.yaml
+      - name: cache
+        value: "always"
+# ...
+----
+
+. Save the changes and exit the editor.
+
+.Verification
+
+. Verify that the resolver cache configuration is applied:
++
+[source,terminal]
+----
+$ oc get configmap resolver-cache-config -n openshift-pipelines -o yaml
+----
++
+[source,terminal]
+----
+apiVersion: v1
+data:
+  max-size: "1000"
+  ttl: "5m"
+kind: ConfigMap
+# ...
+----
+
+. Check cache annotations on a resolved resource:
++
+[source,terminal]
+----
+$ oc get pipelinerun <pipelinerun_name> -o yaml | grep -A 5 "resolution.tekton.dev"
+----
++
+[source,terminal]
+----
+annotations:
+  resolution.tekton.dev/cache-hit: "true"
+  resolution.tekton.dev/cache-timestamp: "2024-01-15T10:30:00Z"
+----
+
+[NOTE]
+====
+Resolver caching improves reliability by reducing external API calls and latency for frequently accessed resources. Cache hits, misses, and timestamps are recorded in resource annotations for observability.
+====