Open jangel97 opened 8 months ago
Transferring this issue to tektoncd/triggers
as it's about TriggerBinding
, which is in it.
Default param values can be set in the TriggerTemplate. These are used in a number of cases including when the TriggerBinding is unable to provide a value. See the docs for more details: https://tekton.dev/docs/triggers/triggertemplates/#specifying-parameters
Tekton applies the value of the default field for each entry in the params array of your TriggerTemplate if it can’t find a corresponding value in the associated TriggerBinding or cannot successfully extract the value from an HTTP header or body payload.
Is this suitable for your needs? If not, any details on the gaps would be helpful for the maintainers.
Use Case: Managing DNS Records for LoadBalancer Services with Knative and Tekton
Context
In our current workflow, we use Knative to trigger a Tekton
EventListener
when a Kubernetes service of type LoadBalancer is removed. The purpose of this trigger is to initiate a pipeline that removes the corresponding DNS records from our intranet, ensuring that our DNS configuration remains up-to-date and free of stale entries.Challenge
The challenge arises when dealing with optional annotations on the Kubernetes service. These annotations provide critical information for the DNS record removal process. However, when a service is deleted, we lose access to these annotations, and since they are optional, we cannot guarantee their presence in every service.
In the current Tekton TriggerBinding implementation, there is no way to specify default values for parameters. This limitation becomes a significant issue in our scenario because:
Lack of Default Values: When a service is deleted, and certain optional annotations are not present, our TriggerBinding cannot bind these missing values. This lack of information leads to incomplete or erroneous pipeline execution.
Error Handling Complexity: Without default values, we have to implement complex error handling in our pipelines to manage missing data, which adds unnecessary complexity and potential failure points.
Proposed Solution
By enabling default values in
TriggerBinding
parameters, we can significantly streamline our pipeline. For instance, if an optional annotation is not present, the TriggerBinding could use a predefined default value, allowing the pipeline to proceed smoothly with known defaults. This enhancement would simplify our pipeline logic and reduce the risk of errors due to missing data.Example
Here's an example of how this feature could be used in our scenario:
In this example, if the
optionalAnnotation
is not present in the service being deleted, theTriggerBinding
would use"default-value"
as the fallback, ensuring that the pipeline has all the necessary information to proceed.Benefits
Implementing this feature would: