Dogfooding Roadmap - Tekton Based CI/CD for Tekton

[afrittoli]

Feature request

This is an overall Epic to track various features and work related to dogfooding - setting a roadmap for the work.

Use case

The reasoning and design behind the dogfooding work is captured in TEP-0066.

Roadmap

• [ ] Store pipeline definitions along the code
  • Related work:
    • Tekton Workflows
    • Pipelines as Code
    • Pipelines as Code TEP
    • Remote resolution TEP
• [ ] Storing and visualising execution history and logs
  • Related work:
  • Tekton Results
  • Tekton Dashboard
    • Dashboard and external logs - prototype
    • Dashboard and results integration
    • Enhanced filtering capabilities - for instance click to filter labels
• [ ] Software Supply Chain Security
  • [ ] Limit the execution based on PR owner

    • 482

    • See existing interceptor
    • Bringing Tekton itself to SLSA level N compliance
• [ ] Tekton CI Features, Optimisations and Fixes
  • [ ] #1131
  • [ ] Handling concurrent updates to a shared resource (Pull request)
    • https://github.com/tektoncd/experimental/issues/699
    • https://github.com/tektoncd/pipeline/issues/2828
  • [x] #888
  • [ ] #626
  • [ ] #886
  • [x] #483
  • [x] #885
• [ ] Tekton CD Features, Optimisations and Fixes
  • [ ] Deletion of resources not handled by the Task that syncs folders to the cluster
  • [x] #778
  • [ ] #62
  • [ ] #884
  • [x] #887

[ghost]

Another idea for possible further discussion that came up on Slack today would be to limit write access to the dogfooding cluster. I know that I've accidentally applied development versions of Tekton Pipelines to dogfooding in the past because I mistakenly left my kubectl config pointing at it the next day after a release. We document steps to avoid this as part of pipelines' release notes but mistakes can happen regardless.

So the idea would be to provide temporary write access to the cluster for releases and "break-glass" emergencies. Ideally this access should last for only a very short time - an hour maybe? It would also be great if it required some kind of public request or submission process so that we have a record of who had access, the reason for it, and when it was granted.

[vdemeester]

@sbwsg I agree with that, I think for 100% of cases (even release of all components), we shouldn't need direct access to the cluster

[xchapter7x]

/area s3c

[vdemeester]

/area roadmap

[lbernick]

@afrittoli I noticed we also have a project board tracking the work we need to do for dogfooding (https://github.com/orgs/tektoncd/projects/29); would it make sense to close out this issue in favor of tracking these work items on the project board?