| status | title | creation-date | last-updated | authors | |
|---|---|---|---|---|---|
proposed |
Common Repository Configuration |
2021-11-19 |
2021-11-29 |
|
- Summary
- Motivation
- Requirements
- Proposal
- Design Details
- Test Plan
- Design Evaluation
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Upgrade & Migration Strategy (optional)
- Implementation Pull request(s)
- References (optional)
Several projects and designs currently in-flight in the Tekton ecosystem are related to or directly working with source repository-related information. These include:
Each of these projects are dependent on information from repositories - either querying for metadata, fetching content, listening for events, recording relatational data about them or publishing notifications to them.
Given a shared interest in this data across multiple projects it might make sense to define an object that allows an operator to specify common repo configuration only once, rather than per-project. Over time other projects and tools could also leverage this information.
Source repositories hold a unique position in CI/CD, not only as versioned storage for code but also as a source of events, target of notifications like test status updates, source of tasks and pipelines, "single pane of glass" for developers, and so on. It therefore makes sense that several Tekton components are designed to work directly with source repos, either reading or writing to them in some way.
The core motivation for this TEP is to model source repos explicitly in Tekton's domain so that components that work with them have a shared set of configuration describing them.
The precise scope of this TEP depends on results of experimenting with this design prior to defining a proposal.
- Decide if there is a common subset of repository data that would be useful across multiple projects.
- Design a format to store and record that common data.
- Publish developer-facing docs for projects to use.
- Publish user-facing docs for operators/cluster admins/app teams to use.
- Mutable
status. This TEP is not aiming to offer a way for concurrent processess to modify shared state or communicate about state changes. Components can read and respond to the shared Repository configuration data but shouldn't expect access to write back to it. - A standard for inferring or storing provenance information related to source code or repositories. This kind of data modelling is kept to the domain of individual components rather than mandated by the common repository configuration.
- Defining interfaces between components for repository data, for example in Pipeline params. Instead this TEP can lean on the work from the dictionary params TEP, which sets the way for those interfaces to be defined.
These use-cases were primarily taken from the Workflows WG meeting notes on Nov 16, 2021.
- A component could read the type, provider and API endpoint info from
the common repo config to determine how to convert
CloudEventsfrom Pipelines into status updates on that repo. - A component could record history related to a Repository object (e.g. the set of PipelineRuns that have been started as a result of events from that Repo) and then provide services based on that history (e.g. "clean up all the PipelineRuns started for this Pull Request on that Repo" or "return a summary of all PipelineRuns started for this repo in the past 7 days").
- A UI component could look up the website URL to link to in order to view detailed pull request information in that repo.
- A component could observe Repository objects and automate setting up
EventListenersandTriggersfor it. - A component could keep a cache of the contents of a repo pointed at by a Repository object for use as a source of Pipelines and Tasks.
- A component could read info from the common config to decide which branches
or commits to poll for updates on, and which API endpoints to hit.
- Con: This might end up being too-specific data to include in common configuration since it is likely to be specific to individual triggers.
In all of these instances each of the services/components could independently require configuration of specific repos. The value of a shared repository object would be in having a single place for this configuration info to live.
- Maintain multiple schemas / config types to avoid repetition. E.g. host information is likely to be same across many repositories and might therefore be a good candidate to have its own schema that repository configuration can reference.