You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: resolve steps referencing StepActions in concurrently
Avoids unnecessary DeepCopy operations on steps that do not reference a StepAction.
Introduces concurrent resolution of steps that reference StepActions to improve the performance of TaskRun reconciliation, especially when using remote resolvers like git. The key changes include:
- `hasStepRefs` function: A new function that quickly checks if a `TaskSpec` contains any steps referencing `StepActions`. This allows for an early exit if no resolution is needed, avoiding unnecessary work.
- `resolveStepRef` function: This new function encapsulates the logic for resolving a single `StepAction` reference. It handles fetching the remote resource, merging the `StepAction` with the step's specification, and returning the resolved step
- Two-phase resolution: The `GetStepActionsData` function is now split into two distinct phases:
- Concurrent Resolution: All `StepAction` references are resolved concurrently using an `errgroup`.
- Sequential Merging: The resolved steps and their provenance are merged into the final step list and the `TaskRun` status sequentially.
- `updateTaskRunProvenance` function: A dedicated function for updating the TaskRun's status with provenance information.
The maximum number of StepActions that can be resolved concurrently is defined by the default config and its `default-step-ref-concurrency-limit` key.
@@ -782,6 +783,33 @@ If `enable-wait-exponential-backoff` is not set or is set to `"false"`, the cont
782
783
783
784
**Note:** This feature is especially useful in clusters where webhook services (such as Kyverno, OPA, or custom admission controllers) may be temporarily unavailable or slow to respond.
784
785
786
+
## Limiting Step reference concurrency resolution
787
+
788
+
You can control the maximum number of concurrent goroutines that the Tekton controller uses to resolve steps referencing a `StepAction` via the `step.ref` field.
789
+
790
+
When a `TaskRun` is processed, any step that uses a `ref` to a remote `StepAction` (e.g., one stored in a git repository or an OCI registry) triggers a fetch request. If a `Task` contains many such steps, the controller will attempt to resolve them all in parallel. This can lead to a "thundering herd" problem, potentially overwhelming remote servers, hitting API rate limits, saturating network resources, or placing excessive load on the Kubernetes API server and the Tekton controller itself.
791
+
792
+
To mitigate this, Tekton Pipelines includes a configurable concurrency limit. By default, a sensible limit is already in place to ensure stability.
793
+
794
+
#### Default Behavior
795
+
796
+
If the `default-step-ref-concurrency-limit` key is not setin the `config-defaults` ConfigMap, Tekton Pipelines defaults to a concurrency limit of **5**. This provides a safe, built-in throttle without requiring any initial configuration.
797
+
798
+
#### Overriding the Default
799
+
800
+
You can override this default to better suit your environment's capacity (e.g., a high-capacity, self-hosted git server might allow for a higher limit). To change the limit, set the `default-step-ref-concurrency-limit` key in your `config-defaults` `ConfigMap`.
801
+
802
+
**Example**: To increase the concurrency limit to 20:
0 commit comments