Tektoncd project convention for pipeline-as-code about plumbing HOT 16 CLOSED

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.

from plumbing.

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

from plumbing.

@vdemeester: Reopened this issue.

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.

from plumbing.

/reopen this is still very much needed

from plumbing.