IMPORTANT NOTE FOR DOC story

The scoping of this story involves only defining pipeline runs for PAC in a CR and supplying parameters for them in a properties format. Any expansion of the scope will require re-planning.  

Epic Goal

• Evolve the current  PaC model to support variations in how a PaC finds the pipeline templates for its event handlers as well as in-repo formats. 
• This includes 
  • in-cluster pipeline definitions per repository to enable simplified enablement of PaC with out in-repo changes. 
  • DSLs or restricted configuration formats for .tekton directory
  • ability to transition from one format to another as a user needs more customization options 

Why is this important?

•  Allow end users to benefit from all the PaC features, such as the Github App, check API support and validation without actually having to have full pipelines in their repo
• Simplified standard configuration information in their repository allows users to start with PaC, but not have to deal with full tekton syntax.
• reduce the cognitive load for end developers allowing a range of selective to full customization without every repository having copies of pipelines and  reduce the overhead for end users accepting pull requests to install and update pipelines.  

Scenarios

1. See this doc for background  https://docs.google.com/document/d/1MxmrCx60t5XIOiIoliJEyaSWPGv3N3ti1BjD2QaiX3A/edit 

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment