-
Notifications
You must be signed in to change notification settings - Fork 222
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
[TEP-0128]: Scheduled Runs #904
Conversation
46a4f58
to
b19ad8e
Compare
b19ad8e
to
044f8b8
Compare
API WG - this is mainly triggers project related changes. Please bring this to triggers WG or Slack channel. |
|
||
### Bindings | ||
|
||
As part of future work for this proposal, we can add two new variable replacements in bindings: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I like this idea!
teps/0128-scheduled-runs.md
Outdated
similar to the kubectl functionality `kubectl create job --from=cronjob/my-cronjob`, for example: | ||
|
||
```sh | ||
tkn eventlistener start <el_name> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 A more general purpose could be a nice addition too tkn eventlistener start -t trigger-name --body ${}
etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea, added this example syntax
f6217ab
to
e6e5f83
Compare
triggers: | ||
- triggerRef: experimental-release-pipeline |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have plan to support reference for Eventlistener as well ?
Thinking like CronTrigger will trigger based on given schedule so if ref is for Eventlistener then it will create Eventlistener object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To check my understanding, you're wondering if we'd plan to support a reference to an EventListener within a CronTrigger, and the CronTrigger would send a fixed event to that EventListener on a schedule? I don't have plans to include that in a proposal but I'm curious if there's a use case you have in mind for that feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No usecase as of now but just thought like if someone need to execute EL based on cronTrigger
But ya proposal can be enhanced in future if we get such use case scenario
/assign @afrittoli |
7c1817f
to
6de5c6a
Compare
@afrittoli @savitaashture if you have time to take a look at this proposal I'd love to merge it during monday's WG! |
This commit splits TEP-0083 (scheduled and polling runs) into two TEPs, one for scheduled runs and one for polling runs, and adds an implementation plan for scheduled runs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lbernick, this looks great to me.
I will leave it to the triggers team to decide whether this has enough details for the TEP to me marked as implementable. Perhaps a diagram of the CRDs involved and their relationship could be helpful, but maybe it's just me :)
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, dibyom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@savitaashture are you able to weigh in here? |
Thanks @lbernick for putting the details thought 👍 |
/lgtm |
This commit splits TEP-0083 (scheduled and polling runs) into two TEPs, one for scheduled runs and one for polling runs, and adds an implementation plan for scheduled runs.
/kind tep