Comments (16)
I think it would also be useful to be clear on what the purpose of the convention are, so we can evaluate our options.
The only reason that comes to mind for me is for discoverability in general:
- Discoverability for tools (so tools can operate on a repo and know where to look, and what format to expect)
- Discoverability for users (so they know where to look when understanding how a project's CI works, cuz they want to change it, copy it, debug it)
In the tools discoverability category I can see some sub points (maybe these are out of scope for what you have planned here tho @vdemeester ):
- Avoiding duplication between tektoncd projects
- Applying some kind of standards across tektoncd projects (e.g. all projects should have x % coverage, coverage should only increase, a code of conduct must always be present)
- ?
Experimenting with a DSL (from experimental maybe) or stick with plain yaml ?
I feel like this is a discussion we could make better decisions around if we delay it until after we've established conventions around the existing syntax.
from plumbing.
@bobcatfish Good points. With consideration for a DSL, this could be one determining factor to decide between one file vs a folder, but otherwise could probably be pushed out.
Other questions about the convention: Is it correct to assume convention means nothing is internal hard coded, but rather tooling/platforms like JenkinsX will build on this standard? Like Christie mentioned, is this convention anything other than pathing for the sake of discoverability?
from plumbing.
In the tools discoverability category I can see some sub points (maybe these are out of scope for what you have planned here tho @vdemeester ):
* Avoiding duplication between tektoncd projects * Applying some kind of standards across tektoncd projects (e.g. all projects should have x % coverage, coverage should only increase, a code of conduct must always be present) * ?
+:100:
Experimenting with a DSL (from experimental maybe) or stick with plain yaml ?
I feel like this is a discussion we could make better decisions around if we delay it until after we've established conventions around the existing syntax.
@bobcatfish agreed !
Other questions about the convention: Is it correct to assume convention means nothing is internal hard coded, but rather tooling/platforms like JenkinsX will build on this standard?
@vtereso depends on what you mean by internal hard coded, but yeah, there shouldn't be anything in the core projects (pipeline, triggers, …) that are hard coded for our use. And yeah, the "hope" is that tooling/platforms build on those standards, although it's not a goal per-se (everybody is free 👼 and JenkinsX is already existing and kinda mature, so in this case, I'm not sure it would go towards following those standards if they are far from their approach).
Like Christie mentioned, is this convention anything other than pathing for the sake of discoverability?
Yeah, in the scope of the tektoncd
project at first. I don't want to set a huge goal for this ; at first I just want to make tektoncd
projects using tektoncd
projects to build and all follow the same convention, for the sake of discoverability and less duplication.
from 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.
from plumbing.
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.
from 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.
from 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.
from plumbing.
/remove-lifecycle rotten
/remove-lifecycle stale
/reopen
from plumbing.
@vdemeester: Reopened this issue.
In response to this:
/remove-lifecycle rotten
/remove-lifecycle stale
/reopen
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.
from 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.
from plumbing.
/remove-lifecycle stale
/cc @chmouel @afrittoli
from plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
with a justification.
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
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
from plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
from plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
with a justification.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/close
Send feedback to tektoncd/plumbing.
from plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen
with a justification.
Mark the issue as fresh with/remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with/lifecycle frozen
with a justification./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.
from plumbing.
/reopen this is still very much needed
from plumbing.
Related Issues (20)
- Pull Requests often not updated with results of go coverage tests HOT 6
- CI not responding to test retry commands HOT 5
- Upgrade kind-based integration tests to a newer k8s version HOT 2
- Update dogfooding to the latest releases HOT 1
- Pipeline v0.49.0 HOT 1
- Triggers v0.24.1
- Chains v0.16.0 HOT 2
- Migrate Tekton resources to `v1` HOT 1
- Use matrix dynamic array support HOT 2
- Stop using latest tag for images in test
- pull-tekton-results-go-coverage failing due to not being present in prior build HOT 2
- Plumbing Setup for Additional CI tests for Per-feature Flag Testing Matrix HOT 4
- Prow `crier` component failing
- Plumbing unit tests pending HOT 1
- Reduce the number of image we maintain here HOT 2
- `pull-tekton-pipeline-go-coverage-df` is flaky HOT 1
- Update dogfooding cluster to k8s 1.28
- Update robocat cluster to k8s 1.28
- Update prow cluster to k8s 1.28
- Tekton-powered job status is sometimes not accurate
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plumbing.