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
    • Setup condition for ∈ org or "ok-to-test" label before running Tekton based CI jobs #482
    • See existing interceptor
    • Bringing Tekton itself to SLSA level N compliance
• Tekton CI Features, Optimisations and Fixes
  • Avoid to start pipelines that we don’t need to run #1131
  • Handling concurrent updates to a shared resource (Pull request)
    • Concurrency limiter controller experimental#699
    • Idea: Pipeline Mutexes pipeline#2828
  • Improve reliability of the check-pr-has-kind-label job  #888
  • Multiline comment break the /test [ci-job-name] command for Tekton based jobs #626
  • Introduce a reusable Kind pipeline / task for testing #886
  • Tekton CI should comment on how to re-run tests #483
  • Migrate Tekton based CI to Workspaces #885
• Tekton CD Features, Optimisations and Fixes
  • Deletion of resources not handled by the Task that syncs folders to the cluster
  • Automatically publish an announcement on release #778
  • Add image vulnerability scanning for releases/nightly builds #62
  • Start signing all of our releases (all projects, full and nightly) #884
  • Migrate our Tekton CD folder away from PipelineResources #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?