Create 2020 roadmap 🛣️ #77
Conversation
tekton-robot
added
the
size/L
There was a problem hiding this comment.
We need to add cli, dashboard and operator roadmap docs in here too
/cc @chmouel @danielhelfand @nikhil-thomas @mnuttall @a-roberts @afrittoli
roadmap/README.md
Outdated
| @@ -0,0 +1,148 @@ | |||
| # Tekton Mission and Roadmap | |||
|
|
|||
| This doc describes Tekton's mission and the 2020 roadmap primarily | |||
There was a problem hiding this comment.
This doc should only be on Tekton's mission and main roadmap (aka as "what we want our components" to lead to) and have a ROADMAP document for the each project on their own.
There was a problem hiding this comment.
Question is then, should the ROADMAP for the other project be here or on their own porject ?
There was a problem hiding this comment.
ah kk! as long as we link from here maybe that's the way to go. i suppose on tekton.dev we can (hopefully) bring it all together!
roadmap/README.md
Outdated
|
|
||
| Tekton's mission: | ||
|
|
||
| Be the industry-standard, cloud-native CI/CD platform components and ecosystem. |
roadmap/README.md
Outdated
| 1. Beta for the remaining components | ||
| 1. Beta for [Tekton Triggers](#triggers) | ||
| 1. GA for both Tekton Pipelines and Tekton Triggers |
There was a problem hiding this comment.
We should be less specific on the beta on the tekton level. I would see something more like
We target a beta release for the core component earlier this year, leading to a full GA (1.0) release of a defined set of components
^^ we still need to discuss what we want to do for this, but my feeling is, as the project grows, we may want to have the main components released together and maybe share the same version number (easier to manage).
In a Tekton GA, I wanna see pipeline, triggers, cli and most likely the dashboard ; but in addition to that, I feel we should also target a versionned catalog that has a well defined process (validation, support, …)
There was a problem hiding this comment.
Maybe we can get all the projects to release together, I'd like to weigh the pros and cons, I'm not 100% convinced - perhaps what I can put here can be more general, about making some decisions around this?
I do think it makes sense to be explicit about a beta release of Triggers tho for example.
roadmap/README.md
Outdated
| As the project matures, we also require: | ||
|
|
||
| 1. A website that provides a good landing page for users (tekton.dev) | ||
| 1. Solid, high quality onboarding and documentation |
There was a problem hiding this comment.
This should be an item on its own, tekton.dev and documentation
roadmap/README.md
Outdated
| for [Catalog](#catalog) success | ||
| - [Alternative Task Implementations](https://github.com/tektoncd/pipeline/issues/215) | ||
| - [Local Execution](https://github.com/tektoncd/pipeline/issues/235) | ||
| - Testing and debugging frameworks |
There was a problem hiding this comment.
ah! maybe I need to write up my thoughts here a bit more. I really like how projects like OPA come with their own built in support for testing (https://www.openpolicyagent.org/docs/latest/policy-testing/) and as @imjasonh and I hinted at super briefly in that russian doll talk, we could potentially use the entrypoint binary to expose some cool debugging support (e.g. letting users step through steps)
There was a problem hiding this comment.
oh yeah also tektoncd/pipeline#1289
There was a problem hiding this comment.
now we've also got tektoncd/pipeline#2069
There was a problem hiding this comment.
@nikhil-thomas and I would be working on it. 😸
roadmap/README.md
Outdated
| #### Task Interfaces and PipelineResources | ||
|
|
||
| In alpha Tekton Pipelines, [`PipelineResources`](https://github.com/tektoncd/pipeline/issues/1673) | ||
| were the interface between `Tasks` in a `Pipeline`: they were used for sharing typed | ||
| data and variables between `Tasks`. This is being revisited and the feature has been | ||
| deconstructed into: | ||
|
|
||
| * `workspaces` - A way for a `Task` to declare data it needs and provides without | ||
| needing to know about the underlying mechanism used | ||
| * `Task results` (aka "output params") - A way for a `Task` to provide values as outputs | ||
| which can be provided to downstream `Tasks` | ||
|
|
||
| After adding these features we will once again reconsider the design of `PipelineResources` | ||
| and decide what additional features, if any, we need. | ||
|
|
||
| We will also need to decide how to continue to release and maintain the code that | ||
| is used to build the images used by the existing `PipelineResources`: | ||
| https://github.com/tektoncd/pipeline/tree/master/cmd. | ||
|
|
||
| ### SCM support | ||
|
|
||
| SCM support in 2019 was handled by | ||
| [the PullRequest Resource](https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#pull-request-resource). | ||
| However [we are revisting PipelineResources](#task-interfaces-and-pipelineresources), | ||
| and likely this `PipelineResource` will become one or more `Tasks` in | ||
| [the catalog](https://github.com/tektoncd/catalog) instead. Once that happens, | ||
| we will need to make decisions about how to release and maintain the | ||
| supporting code. | ||
|
|
||
| * [GitHub App support](https://github.com/tektoncd/triggers/issues/189) | ||
| * Support for more SCM providers | ||
|
|
||
| ### Results | ||
|
|
||
| One of the benefits of [defining specifications around CI/CD](#mission-and-vision) | ||
| is that we can start to create tools around inspecting what is moving through our | ||
| Pipelienes. In 2019 we started some design work around a result storage system for | ||
| Tekton, and we want to make progress on this in 2020: | ||
|
|
||
| * Design reporting to results store: https://github.com/tektoncd/pipeline/issues/454 | ||
| * Snapshoting data for history + repeatability: https://github.com/tektoncd/pipeline/issues/279 |
There was a problem hiding this comment.
This should be on a pipeline roadmap file 👼
There was a problem hiding this comment.
Quick thought: I've been thinking of "results" as a new, totally separate project. e.g. i dont think using tekton pipelines should require using tekton results, kinda like tekton triggers. what do you think @vdemeester ?
There was a problem hiding this comment.
ah 🙃 then it can be in the main "tekton" roadmap for now, and we'll update as we go 😝
roadmap/triggers.md
Outdated
| In 2020 we would like to add missing features and then push for | ||
| [Triggers to be Beta and later GA](#beta-and-ga): | ||
|
|
||
| We are targetting improving the experience for both end users and operators: |
There was a problem hiding this comment.
Optional integration with knative maybe ?
There was a problem hiding this comment.
Can you explain a bit more here? I'm still of the opinion that our best bet is to be as generic as possible
There was a problem hiding this comment.
Hence "optional" in my comment 😛 An example would be : using a knative service to expose the EventListener instead of a standard K8S service. I should probably have written "optional integration with knative/serving" maybe 😝
There was a problem hiding this comment.
I guess that could be under improved support for many EventListeners?
There was a problem hiding this comment.
Im unclear of the value in exposing the listener via knative service rather than corev1.Service, and am curious about the improvement it would provide. I do love me some knative serving/eventing and use this combo with triggers regularly but feel like im missing the background.
There was a problem hiding this comment.
@iancoffey not too much, just would like to be able to have a "scale-to-zero" service for event-listener
There was a problem hiding this comment.
Maybe I can include this as "scale-to-zero EventListner"?
tekton-robot
requested review from
a-roberts,
afrittoli,
chmouel,
danielhelfand,
mnuttall and
nikhil-thomas
|
I left some quick responses @vdemeester but I have a feeling I won't be returning to this this week - it's looking like a crazy one. If you want to make any changes to this directly plz do otherwise I'll make sure to get back to this as soon as I can (maybe next week? 🤞 ) |
|
@vdemeester for the Dashboard here's what I'm personally thinking would be useful to have, I'd like to get input from @mnuttall and @AlanGreene before we commit to anything in particular
|
bobcatfish
force-pushed
the
add_2020_roadmap
branch
from
91fbe23
to
792c6a0
Compare
|
@vdemeester Re @a-roberts' comments above on dashboard - we can't promise but Adam's list is very reasonable set of goals. Hopefully we'll make good progress on that list. |
roadmap/triggers.md
Outdated
|
|
||
| * For end users: | ||
| * [Pluggable core interceptors](https://github.com/tektoncd/triggers/issues/271) | ||
| * [Increased expression support in TriggerBindings](https://github.com/tektoncd/triggers/issues/271) |
There was a problem hiding this comment.
This link is incorrect; it has the same link as the previous item. I think that it's supposed to link to issue 367: tektoncd/triggers#367
There was a problem hiding this comment.
whoops, thanks for being thorough @ncskier ! :D
roadmap/README.md
Outdated
| include. | ||
|
|
||
| Features we don't have or aren't yet 100% satisfied with for "feature complete" | ||
| Tekton: |
There was a problem hiding this comment.
Other ideas:
- Looping: Support Task looping syntax inside Pipelines pipeline#2050, Add support for Task Step looping pipeline#2112
- Alternative Task types - e.g. tasks with no underlying pod - for instance when waiting on input for an arbitrarily long time or so.
There was a problem hiding this comment.
for the first, I agree but I know this is a somewhat contentious point!! I'm going to include it b/c between the 2 of us thats 2 people for it XD, maybe I'll include a caveat about deciding if we want to include looping
i think the second is covered by "Alternative Task Implementations" ?
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
I have put together a roadmap for 2020, which attempts to represent the most requested of the features and issues that we've seen so far. I did this by: * [Reviewing the 2019 roadmap](https://docs.google.com/document/d/1zClmMJZU63kEDedjxTI99MCK-mXqm-Ym7PBfjMG5tQE/edit) * Looking at the oldest and most commented on issues in Tekton Pipelines and Tekton Triggers I also added a section on Tekton's mission: this is the mission that we've been using at Google when talking about Tekton - so this is a great chance for anyone who is viewing Tekton differently to mention their mission and vision so we can tweak it. Having more clarity around what everyone is hoping accomplish with Tekton will make it easier to make decisions around features, etc. Roadmaps for individual projects: * Pipelines: tektoncd/pipeline#2275 * Triggers: tektoncd/triggers#498 * Catalog: tektoncd/catalog#236 * Dashabord: TBD, initial thoughts in tektoncd#77 (comment) * CLI: TBD
bobcatfish
force-pushed
the
add_2020_roadmap
branch
from
792c6a0
to
5837ed8
Compare
tekton-robot
removed
the
size/L
tekton-robot
added
the
size/M
|
Okay I finally came back and tried to reply to everything and move roadmaps for each project into their repos: Roadmaps for individual projects:
PTAL @vdemeester @afrittoli |
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
roadmap.md
Outdated
| [does not include all Tekton Pipeline components](https://docs.google.com/document/d/1H8I2Rk4kLdQaR4mV0A71Qbk-1FxXFrmvisEAjLKT6H0/edit#heading=h.t0sc4hdrr5yq), | ||
| we will work toward: | ||
|
|
||
| 1. Beta and GA for all Tekton Projects |
There was a problem hiding this comment.
Should we say all or the core component (and listing thoses: pipeline, triggers, cli, dashboard, ?)
An example is the new hub project, might not follow the exact same pattern (or any newly added project)
roadmap.md
Outdated
| ### Results | ||
|
|
||
| One of the benefits of [defining specifications around CI/CD](#mission-and-vision) | ||
| is that we can start to create tools around inspecting what is moving through our | ||
| Pipelienes. In 2019 we started some design work around a result storage system for | ||
| Tekton, and we want to make progress on this in 2020: | ||
|
|
||
| * Design reporting to results store: https://github.com/tektoncd/pipeline/issues/454 | ||
| * Snapshoting data for history + repeatability: https://github.com/tektoncd/pipeline/issues/279 |
There was a problem hiding this comment.
Isn't this pipeline specific ?
There was a problem hiding this comment.
ah yeah that's true, I'll remove this
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester 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 |
tekton-robot
added
the
approved
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
I have put together a roadmap for 2020, which attempts to represent the most requested of the features and issues that we've seen so far. I did this by: * [Reviewing the 2019 roadmap](https://docs.google.com/document/d/1zClmMJZU63kEDedjxTI99MCK-mXqm-Ym7PBfjMG5tQE/edit) * Looking at the oldest and most commented on issues in Tekton Pipelines and Tekton Triggers I also added a section on Tekton's mission: this is the mission that we've been using at Google when talking about Tekton - so this is a great chance for anyone who is viewing Tekton differently to mention their mission and vision so we can tweak it. Having more clarity around what everyone is hoping accomplish with Tekton will make it easier to make decisions around features, etc. Roadmaps for individual projects: * Pipelines: tektoncd/pipeline#2275 * Triggers: tektoncd/triggers#498 * Catalog: tektoncd/catalog#236 * Dashabord: TBD, initial thoughts in tektoncd#77 (comment) * CLI: TBD
bobcatfish
force-pushed
the
add_2020_roadmap
branch
from
5837ed8
to
44b9ccf
Compare
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
In tektoncd/community#77 we started on a roadmap for 2020 for all of Tekton but folks pointed out it makes more sense to let each project's own roadmap live in the repo with them.
|
/lgtm |
|
/lgtm 🎉 |
1 similar comment
|
/lgtm 🎉 |
|
Thanks all!!! :D |
I have put together a roadmap for 2020, which attempts to represent the
most requested of the features and issues that we've seen so far. I did
this by:
and Tekton Triggers
I also added a section on Tekton's mission: this is the mission that
we've been using at Google when talking about Tekton - so this is a
great chance for anyone who is viewing Tekton differently to mention
their mission and vision so we can tweak it. Having more clarity around
what everyone is hoping accomplish with Tekton will make it easier to
make decisions around features, etc.
PTAL:
And everyone else of course!!!!
Roadmaps for individual projects: