Add a Pipeline Wizard

What does this MR do and why?

This MR introduces a Pipeline Wizard Vue Component. The Pipeline Wizard is a configurable tool that allows GitLab developers to create an interactive UI that guides users through the creation of a .gitlab-ci.yml file.

It is use-case agnostic: It can be used to configure pipelines for Docker Images, Packages, Mobile apps, Infrastructure,... anything you can think of. While it was originally written to support the onboarding to GitLab Pages, anything related to the specifics of the Pipeline's use (Labels, descriptions, validation etc.) is defined in a config file (yet another yaml* file).

How does it work?

The pipeline wizard component accepts a YAML-formatted string as a template property. That yaml string should look like the contents of this file

<script>
 import template from './my-template.yml'
</script>

<template>
  <pipeline-wizard :template="template" />
</template>

The template file

The Pipeline Wizard expects a single template file that configures the user flow. But the wizard is agnostic with regards to the contents of the file, so ultimately the wizard can be used to display a range of different pipeline-builder-flows:

E.g. there can be one template file for Static Sites, one for Docker Images, one for Mobile Apps, and so on. As a first iteration, these templates can be part of the GitLab source code, but later they could live in an outside repository like this one, opening up the possibility for Workspace Admins to maintain their own use-case specific pipeline wizards.

The template file defines multiple Steps. (See an example file)

An ideal onboarding experience consists of 2-3 Steps for a total of 3-4 Steps visible tho the user. The last step shown to the user will always be the commit and is not part of the template definition.

Steps

A Step is basically a page in a multi-step (or page) process: A set of related input fields that build a part of the final .gitlab-ci.yml:

Example for a Step definition:

inputs:
  - label: Build Steps
    description: "Enter the steps necessary to build a production version of
      your application."
    widget: list
    target: $BUILD_STEPS
  - label: Select a deployment branch
    description: "Select the branch we should use to generate your site from.
      we will trigger a re-build of your site any time you push to this
      branch."
    widget: branch-selector
    target: $BRANCH
template:
  pages:
    script: $BUILD_STEPS
    artifacts:
      paths:
        - public
    only:
      - $BRANCH

A Step includes two properties (probably more to come):

• inputs: A list of input definitions. Each item in inputs corresponds to one variable (e.g. $BUILD_STEPS) in the template section
• A template section that contains the raw yaml that will be deep-merged into the final .gitlab-ci.yml. This template section can contain variables denoted by a $ sign that will be replaced with the values from the input fields.

Input

Each Step can contain one or more input definitions. For an ideal user experience, it does not contain more than 3. The input definition has the following properties:

• label (required): The label for the input field
• target (required): The variable name inside the step's template that should be replaced with the value of the input field
• description: A help text / description related to the input field
• required: A boolean indicating whether or not the input field is required before proceeding to the next step
• widget: The widget to use for the input, corresponds to the name of the Vue component that is used. In simple cases this corresponds to the input type, but can be enhanced with more options. Eg. text, number, list, branch-selector - the number of options can grow with the use-cases.
• placeholder (only for widgets that support this functionality)
• default: a default value to prefill the input element with
• pattern: A Regex pattern to validate the input against (only for widgets that support this functionality)
• invalid-feedback: The error message displayed to the user in case the pattern validation fails

Examples:

Example for a list widget:

Two input fields, one list-widget, one branch-selector-widget (Note: the branch-selector-widget is not part of this MR):

How to set up and validate locally

Because this MR is already huge, this MR only contains the Component, but it isn't used in the UI yet. The first use has been moved into a different MR. If you would like to see the Wizard in action, check out !78276 (merged). That MR is based on this one and includes the usage of the Wizard in GitLab Pages.

Once you have checked out that other branch, follow the below steps locally:

1. enable the use_pipeline_wizard_for_pages feature flag by opening the rails console with rails c and then toggling the flag with Feature.enable(:use_pipeline_wizard_for_pages)

2. Log in to your local GitLab instance, open a project that does not yet have a pages deployment.

3. Inside the project, navigate to Settings > Pages.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.