-
Notifications
You must be signed in to change notification settings - Fork 419
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
CLI tool for manual Trigger runs #624
Comments
Any reason for not pushing for having this in |
Reading this, it sounds like more of a proof of concept/basic requirements at this point and could potentially be added to But I would see no reason not to want something like this as part of |
yeah, one motivation for keeping this in Triggers would be faster/easier iteration -- we'd have to do some refactoring to how we execute a Trigger to ensure we can run it outside the context of an EventListener. Once that is done, it should be easy enough to make it part of the |
This part one contians the funcstions to parse yaml file and HTTP, and the corresponding unit test. It relates to issue tektoncd#624.
This part one contians the funcstions to parse yaml file and HTTP, and the corresponding unit test. It relates to issue #624.
The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger CRDs, we need a mechanism to handle triggers consisently, regardless of their originating type. As a first step, this allows for `TriggerSpec` to be converted to `EventListenerTrigger` in order to reuse existing libraries. Part of the work required for tektoncd#624.
The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger CRDs, we need a mechanism to handle triggers consisently, regardless of their originating type. As a first step, this allows for `TriggerSpec` to be converted to `EventListenerTrigger` in order to reuse existing libraries. Part of the work required for tektoncd#624.
The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger CRDs, we need a mechanism to handle triggers consisently, regardless of their originating type. As a first step, this allows for `TriggerSpec` to be converted to `EventListenerTrigger` in order to reuse existing libraries. Part of the work required for #624.
…l referenced bindings, find the trigger template, apply the HTTP request to the binding and template the part for ProcessTriggerSpec Add the part one of CLI for trigger run. This part one contians the funcstions to parse yaml file and HTTP, and the corresponding unit test. It relates to issue tektoncd#624. Add unit test for processTriggerSpec Add unit test for processTriggerSpec Add ProcessTriggerSpec function to take a Triggers.yaml file, find all referenced bindings, find the trigger template, apply the HTTP request to the binding and template Add unit test for processTriggerSpec
…l referenced bindings, find the trigger template, apply the HTTP request to the binding and template the part for ProcessTriggerSpec Add the part one of CLI for trigger run. This part one contians the funcstions to parse yaml file and HTTP, and the corresponding unit test. It relates to issue tektoncd#624. Add unit test for processTriggerSpec Add unit test for processTriggerSpec Add ProcessTriggerSpec function to take a Triggers.yaml file, find all referenced bindings, find the trigger template, apply the HTTP request to the binding and template Add unit test for processTriggerSpec
This part one contians the funcstions to parse yaml file and HTTP, and the corresponding unit test. It relates to issue tektoncd#624.
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
We have some experimental code for this that processes Triggers locally. We should do a release for it and then figure out if it makes sense to merge that into the CLI |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/remove-lifecycle rotten |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Expected Behavior
I can easily test out their Trigger config e.g. does the CEL expression work, does my binding expression extract the right variable, does my trigger template replace the right variable etc.
Actual Behavior
I have to setup an EventListener, TriggerBinding, and TriggerTemplate. I have to port-forward to the Listener, and make a curl call, and then look into the Listener logs to figure out what happened.
Additional Info
Example CLI surface from discussing with @bigkevmcd :
Out of scope for now:
Can be added later:
tkn
surface e.g.tkn trigger run ....
Related :
/kind feature
The text was updated successfully, but these errors were encountered: