K8S-styled templating - remove triggers' XYZTemplates, template types, template definitions, and variable interpolations from trigger controllers and triggers API about triggers HOT 7 CLOSED

https://github.com/tektoncd/triggers/blob/master/config/300-triggertemplate.yaml As a simple edit, I will remove this file in a pull request. This suggestion is open for comments
Will of course also impact https://github.com/tektoncd/triggers/blob/master/pkg/apis/triggers/v1alpha1/trigger_template_types.go among other locations, though those can come in other pull requests

If Triggers wants to make its own templating decisions independent of Tekton's overall decisions on templating, that may also be discussed in this context

Better to ask and decide on this now, while the API is still in alpha and many parts are not-yet-implemented

from triggers.

tektoncd/pipeline#850

from triggers.

Hey! Thanks for opening this. I think the discussion last week you're citing here has a few impacts on the rest of the project, and we especially need to think carefully through how to apply these rules to the triggering project here.

Tekton will avoid templating most forms of variable interpolation at the API layer for Tekton.

I agree here. Where possible interpolation should happen before calling the API. Some notable exceptions in k8s already exist though. Here is one: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config

This will also mean avoiding creating any objects named "XYZTemplate" and/or "XYZTemplateType" in favor of allowing external tools to be chosen by a developer for generating the API calls/YAML/JSON files.

I don't think this is quite accurate, and Template is unfortunately an overloaded name. See the way PodTemplates are exposed in k8s Deployment objects for a case where Template is being used correctly by the core k8s system: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

I think that's the logical equivalent of what we're trying to do in Triggers. Provide a declarative mechanism for a Trigger to create a Resource on demand, similar to the way a Deployment can create a Pod on demand.

So, I think I am not going too far out there to state: Let us not add too many intelligent forms of template logic into the controllers.

+1 to this!

from triggers.

affects pipelines and triggers https://docs.google.com/document/d/11QWLYPP-yj_K_ghQqHr3LFonFE9bfHwtooYq6qPhn8w Less Template, More Tekton

from triggers.

@dlorenc Let's consider to not publicly publish a mechanism for cookie-cutting from a set of intermediate template resources, even if similar mechanisms are used internally or encouraged externally such as in a git repository or using a template publishing tool. I saw fairly convincing arguments in the "Declarative Application Management" document https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md I prefer doing less where possible, and this document outlines methods appealing to that side of me

from triggers.

I'm pretty familiar with that document, but I'm not sure I follow how we would address the same use cases without having a mechanism to create resources when an event is triggered.

Could you explain more? I'm hesitant to remove any of these features until we fully understand the replacements.

from triggers.

As mentioned in #26 (comment) and #24 (comment) I'm hoping we can reduce the number of places we are discussing completely removing our templating & template types so I'd like to close this issue for now.

from triggers.