triggers: CLI tool for manual Trigger runs
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 :
triggers-run -H "X-GitHub-Event: testing" -d @testing.json -f triggers.yaml
- triggers.yaml is a file containing the trigger definitions
- The CLI supports curl like flags for sending headers and body
- The tool will prints out the trigger processing logs to stdout
- It will also print out the fully formed Tekton resource to be created once the trigger is processed instead of creating them
Out of scope for now:
- Testing Trigger level service account permissions
Can be added later:
- Actually create the resources instead of just printing them out
- Dry run against a already running listener instead of definitions from a file
- Make it part of the
tknsurface e.g.tkn trigger run .... - Account for the Trigger service account permissions
Related :
/kind feature
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (7 by maintainers)
Commits related to this issue
- 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 #624. — committed to dorismeixing/triggers by dorismeixing 4 years ago
- 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 #624. — committed to tektoncd/triggers by dorismeixing 4 years ago
- Add ToEventListenerTrigger conversion func. The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger C... — committed to wlynch/triggers by wlynch 4 years ago
- Add ToEventListenerTrigger conversion func. The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger C... — committed to wlynch/triggers by wlynch 4 years ago
- Add ToEventListenerTrigger conversion func. The existing `resolveTrigger` and related Trigger processing functions currently assume an `EventListenerTrigger` input. With the introduction of Trigger C... — committed to tektoncd/triggers by wlynch 4 years ago
- 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 the part for ProcessTriggerSp... — committed to dorismeixing/triggers by dorismeixing 4 years ago
- 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 the part for ProcessTriggerSp... — committed to dorismeixing/triggers by dorismeixing 4 years ago
- 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 #624. — committed to dorismeixing/triggers by dorismeixing 4 years ago
Reading this, it sounds like more of a proof of concept/basic requirements at this point and could potentially be added to
tknlater on (e.g.tkn trigger rununderCan be added later) if understanding correctly? Either as part oftknitself or maybe could be added as some type of plugin totknif that would be a more preferred route.But I would see no reason not to want something like this as part of
tkn. Just would maybe need some thought on where it would best fit structurally.