[TEP-0098] Propose adopting Pipelines as Code #936
Conversation
tekton-robot
added
the
kind/tep
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
do-not-merge/work-in-progress
lbernick
force-pushed
the
pac
branch
2 times, most recently
from
e3e340b
to
234de9b
Compare
| TODO | ||
| As proposed in [#866](https://github.com/tektoncd/community/issues/883), Pipelines as Code will be adopted into the tektoncd organization. | ||
| It will be built and released as a Tekton project, and renamed to "Workflows", since the scope | ||
| of the Workflows project is larger than storing Pipelines in version control. |
There was a problem hiding this comment.
if we are talking about the project name rename, I am not against it. but we are going to need to do have to do a fair amount of work from our side to get our product using the renamed version if that happen.
Thinking a bit, I wonder if there workflow can be an umbrella of components that can be picked up by distributor/users.
There would be things like:
pac
concurrency
scheduling
notificatons
and other components
some sort of strong integration between all of them and common objects like RepoSitory CRD, but users would pick the thing they want.
| - **Variable replacement**: The existing API uses syntax like `{{ repo_owner }}` within a PipelineRun, but this syntax does not work if defined | ||
| in a PipelineRun yaml and applied to a cluster. Instead, variable substitutions for repo metadata are permitted only within `workflow.spec.pipelineRun`, | ||
| and Workflows will substitute these values to create a valid PipelineRun. (This is similar to the pattern used in TriggerTemplates.) | ||
| Variable replacement will use `$(context.foo)` syntax instead of `{{ foo }}` syntax, for consistency with existing Tekton projects. |
There was a problem hiding this comment.
I am not sure about the argument for "not work if defined in a PipelineRun yaml and applied to a cluster.".
The advantage of using a straight PipelineRun is that tooling have no issues reading the pac pipelinerun, the templates variable need to be defined, but the PipelineRun visualization tools still works....
I wonder if we could somehow make this inside a custom resolver instead, where we could have a PipelineRun with those {{ variables }} and when the resolver sees it it would replace them with values coming from TriggerTemplates variables (or other CRD who has thos values) ?
|
|
||
| ## Design Details | ||
| - **Remote resolution**: The Pipelines as Code resolver will be replaced with remote resolution. `pipelinesascode.tekton.dev/task-n` |
There was a problem hiding this comment.
👍🏻
there is a few thing that are "context" specific which we need to figure out, for example we would use the github token from the github app to resolve https url going to gitthub.com (or enteprise github) to handle transparently private repositories... but remote resolution is def the goal.
This commit updates TEP-0098: Workflows to be implementable, proposes adopting the Pipelines as Code project, and explains how we will use it to meet our goals with Workflows.
tekton-robot
added
the
needs-rebase
|
@lbernick: PR needs rebase. 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. |
|
At the last workflows WG, @chmouel mentioned that RedHat folks like the general approach of this proposal, but can't commit resources right now to migrating Pipelines as Code -> Tekton Workflows. I think the best way forward is to focus on incremental feature development as needed for our dogfooding. I'm hoping this will reduce the scope of what we're trying to do and build features based on concrete, immediately necessary use cases, that can also be used in Pipelines as Code and other higher level apis. |
This commit updates TEP-0098: Workflows to be implementable, proposes adopting the Pipelines as Code project, and explains how we will use it to meet our goals with Workflows.
/kind tep