Tektoncd project convention for pipeline-as-code

[vdemeester]

This has been discussed a tiny bit during last working group.

As of today, each project that uses Tekton to do some work (release most likely), is using a tekton folder. Now that we are getting more into dogfooding and that we are able to start experimenting with pipeline-as-code (thanks to tektoncd/triggers and #100, we should try to define a convention for the tektoncd projects (nothing official yet).

Few questions we may want to answer

• One file vs a folder with multiple files possible ?
• Hidden folder or not (aka tekton/ vs .tekton/) ?
• Experimenting with a DSL (from experimental maybe) or stick with plain yaml ?

All those questions do not need to be answer at the same time, and the answer might evolve over time. This issue is there to track the work around that.

/cc @bobcatfish @dibyom @skaegi @chmouel @mnuttall @imjasonh @vtereso @afrittoli @dlorenc @sbwsg @akihikokuroda @abayer

[bobcatfish]

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.

[vtereso]

@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?

[vdemeester]

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.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

@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.

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@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.

[tekton-robot]

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.

[vdemeester]

/remove-lifecycle stale
/cc @chmouel @afrittoli

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

@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.

[afrittoli]

/reopen this is still very much needed