triggers
triggers copied to clipboard
FR: Dynamic TriggerTemplate Resources
Motivating Use Case
Be able to run/test Tekton Trigger configurations ephemerally without needing to apply it permanently to the cluster. e.g. how do I test a change to a Template/Pipeline config?
Proposed Solution
Add a new type that can be included in TriggerTemplates that will read configuration dynamically from a file.
This type should take a volume generating resource (such as GitResource or StorageResource) as an input.
Example
apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
name: pipeline-template
spec:
resourcetemplates:
- apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: git-repo
spec:
type: git
params:
- name: revision
value: $(params.gitrevision)
- name: url
value: $(params.gitrepositoryurl)
- apiVersion: tekton.dev/v1alpha1
kind: DynamicResource
metadata:
name: dynamic-resource
spec:
path: '/path/to/my/config.yaml'
inputs:
resourceRef:
name: git-repo
Where /path/to/my/config.yaml references a file containing other TriggerTemplate resources (example)
Open Questions
- Will there be any issues in order when referencing a Resource from another Resource?
- Name? DynamicResource? FileResource?
TODO
- [ ] Write full design
- [ ] Implement
/assign wlynch
/kind feature
I am not sure why it should take a PipelineResource. What is the requirement for that ?
Also, related to tektoncd/pipeline#1369, we should make sense that we may (or user may) not use PipelineResource in some cases, and thus, we should make sure our design(s) work without it too :angel:
Here's a pass at a proposal: https://docs.google.com/document/d/1fTob_Y6qo61vl6UIhraV6tSRM9Vb-DrugCyihB6md_Q/edit#
@vdemeester Would particularly like your feedback here, since this has heavy overlap with your catalog URI proposal.
This seems like it could be satisfied with a TaskRun that would kubectl create/kubectl apply a URI? The new PipelineResource design allows for arbitrary additions/injections so there might be overlap there too.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Send feedback to tektoncd/plumbing.
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.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.