Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Await Tekton Webhooks Readiness in Pulumi Deployments #2381

Open
SchahinRohani opened this issue Oct 22, 2024 · 0 comments
Open

Await Tekton Webhooks Readiness in Pulumi Deployments #2381

SchahinRohani opened this issue Oct 22, 2024 · 0 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@SchahinRohani
Copy link

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?

@SchahinRohani SchahinRohani added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

1 participant