-
Notifications
You must be signed in to change notification settings - Fork 110
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
Towards tektoncd project with no dependencies to plumbing #103
Comments
I would worry about I think 2. is a reasonable mid-term fix to our issue, that's not too hard to implement. Solution 3. is a rather attractive long term solution but I guess we will need to speak about it more before getting there. Just to mention it, while I was working on OpenStack, they had this openstack-common (oslo it was called) thing that was imported/updated and committed directly into projects. It wasn't pretty and had its own set of issues but it was rather working for a while..... |
I think (3) is the way to go, I don't see the need for intermediate steps. We need some design about how we are going to share plumbing tasks (and Tekton resources in general) to the other projects. We also need to decide / design whether the entry point of CI jobs will stay in plumbing or if it will in each repo or both. It would be nice if the model we adopt for plumbing embodied the recommended setup that organisations can use to define their own tekton based CI/CD. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
Related to tektoncd/triggers#180 (comment) — use go modules for
tektoncd/triggers
. This issue aims to discuss and track a way to make so thattektoncd
projects do not need explicit dependency totektoncd/plumbing
.Today, most of the projects (
tektoncd/pipeline
,tektoncd/cli
, …) use a small hack withdep
orgo mod
to get a specific version ofpluming
scripts as a go dependency. As @bobcatfish highlight, this highlight an historical odd thing with plumbing (inherited fromknative
).We should aim towards a
tektoncd/plumbing
dependency-free. Having all project usingtekton
pipelines is the end goal and would make those projects standing on their own,tektoncd/plumbing
would be the infra setup and cross project CI/CD if any. That said, as discussed on the issue with @bobcatfish, we should do this in several step, ensuring all project are doing the same (easier to follow and adapt).Here are my initial proposals
tektoncd/experimental
is using something different too, so we are gonna need to change that in any casegit submodules
😝. I (and @bobcatfish too) have little experience with them in the past few years so, not sure what to think about it yet.test-runner
image used for CI (with prow), so that we don't need to have any as dependency. This would force us to use script only for CI and make sure anything can run locally without those scripts (and document this)tektoncd
organization)./cc @bobcatfish @dibyom @skaegi @chmouel @mnuttall @imjasonh @vtereso @afrittoli @dlorenc @sbwsg
The text was updated successfully, but these errors were encountered: