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
Provide a mechanism within the Tekton Operator to enable users to wait for the webhooks to become ready before proceeding with the deployment of Tekton resources.
Use case
We are using Pulumi to spin up a local Kind cluster, install the Tekton Operator, and then apply our Tasks, Pipelines, and Triggers. During this process, we've encountered an issue:
After the Kind cluster starts and the Tekton Operator installs all necessary components, there is no straightforward way to wait for the Tekton webhooks to become ready before proceeding with applying our Tekton resources. This leads to intermittent failures because the webhooks may still be in an unready state when we attempt to deploy our Tasks, Pipelines, PipelineRuns, and Triggers.
Pulumi has introduced a new pulumi.com/waitFor annotation for per-resource readiness checks, as detailed here: Improved Kubernetes Await Logic. This feature allows us to wait for specific Kubernetes resources to become ready before moving forward with the deployment.
However, since the Tekton webhooks are installed as separate components by the Tekton Operator, we can't directly hook into them using the waitFor annotation. This limitation prevents us from reliably ensuring that the webhooks are ready before applying our Tekton resources.
Question:
We have looked for a straightforward solution to this but couldn't find one. Maybe we have overlooked something? Is there a straightforward solution to this without implementing custom Go/Pulumi await or querying Kubernetes logic?
The text was updated successfully, but these errors were encountered:
Feature request
Provide a mechanism within the Tekton Operator to enable users to wait for the webhooks to become ready before proceeding with the deployment of Tekton resources.
Use case
We are using Pulumi to spin up a local Kind cluster, install the Tekton Operator, and then apply our Tasks, Pipelines, and Triggers. During this process, we've encountered an issue:
After the Kind cluster starts and the Tekton Operator installs all necessary components, there is no straightforward way to wait for the Tekton webhooks to become ready before proceeding with applying our Tekton resources. This leads to intermittent failures because the webhooks may still be in an unready state when we attempt to deploy our Tasks, Pipelines, PipelineRuns, and Triggers.
Pulumi has introduced a new pulumi.com/waitFor annotation for per-resource readiness checks, as detailed here: Improved Kubernetes Await Logic. This feature allows us to wait for specific Kubernetes resources to become ready before moving forward with the deployment.
However, since the Tekton webhooks are installed as separate components by the Tekton Operator, we can't directly hook into them using the waitFor annotation. This limitation prevents us from reliably ensuring that the webhooks are ready before applying our Tekton resources.
Question:
We have looked for a straightforward solution to this but couldn't find one. Maybe we have overlooked something? Is there a straightforward solution to this without implementing custom Go/Pulumi await or querying Kubernetes logic?
The text was updated successfully, but these errors were encountered: