Key | Value |
---|---|
Author(s) | Neal.Coleman, Jordan.Brockopp |
Reviewers | Emmanuel.Meinen, Kelly.Merrick |
Date | July 1st, 2019 |
Status | Complete |
Please provide a summary of the new feature, redesign or refactor:
This feature will allow customers to create pipelines across multiple repos from a single blueprint.
This blueprint (a.k.a. template) can be a customized version written by the customer, or an "officially supported" template written by the Vela admins themselves.
The template will support the ability to inject variables from the pipeline sourcing the template to enable flexible utilization and account for atypical use-cases.
This has the added benefit of enabling features like "matrix pipelines" that allow repeating the same set of tasks with different variables.
Similar to the pipeline configuration itself, templates will be written in YAML and enable specific attributes, or even entire sections of the template to be controlled through defined variables.
Please briefly answer the following questions:
- Why is this required?
- customers spend a large amount of time copying CI pipelines across repos and updating few fields.
- bridge the gap of supporting mono repos - Mono repos tend to have identical code in multiple places
- support "matrix builds" that existing CI solutions can perform
- If this is a redesign or refactor, what issues exist in the current implementation?
N/A
- Are there any other workarounds, and if so, what are the drawbacks?
The only workaround that exists is to manually copy and paste the same YAML pipeline across multiple repos. Several drawbacks exist for this method:
- miscalculating the part(s) of the YAML pipeline that are to be copied
- amount of time and effort required to copy/paste between repos
- keeping all repos in sync (up to date) that attempt to use the same YAML
- Are there any related issues? Please provide them below if any exist.
N/A
Please describe your solution to the proposal. This includes, but is not limited to:
- new/updated endpoints or url paths
- new/updated configuration variables (environment, flags, files, etc.)
- performance and user experience tradeoffs
- security concerns or assumptions
- examples or (pseudo) code snippets
version: "1"
steps:
- name: tmpl
template: true
source: github
local: git.example.com/template-repo/stable/spring
variables:
image_name: hello_world
application: hello_world
- name: slack
image: target/vela-slack:latest
format:
message: You ran a build
version: "1"
metadata:
template:
name: git.example.com/template-repo/stable/spring
vars:
image_name: hello_world
application: hello_world
steps:
- name: tmpl
template: true
- name: slack
image: target/vela-slack:latest
format:
message: You ran a build
version: "1"
templates:
- name: spring
source: git.example.com/template-repo/stable/spring
vars:
image_name: hello_world
application: hello_world
steps:
- template: spring
- name: slack
image: target/vela-slack:latest
format:
message: You ran a build
version: "1"
steps:
- template:
name: spring
source: git.example.com/template-repo/stable/spring
vars:
image_name: hello_world
application: hello_world
- name: slack
image: target/vela-slack:latest
format:
message: You ran a build
version: "1"
templates:
- name: spring
source: git.example.com/template-repo/stable/spring
steps:
- name: tmpl # When using templates name is optional
template:
name: spring
vars:
image_name: hello_world
application: hello_world
- name: slack
image: target/vela-slack:latest
format:
message: You ran a build
Please briefly answer the following questions:
- Is this something you plan to implement yourself?
Yes
- What's the estimated time to completion?
2 weeks
Please provide all tasks (gists, issues, pull requests, etc.) completed to implement the design:
After some trials and discussions, Option 5 was chosen!
Please list any questions you may have:
N/A