Blog Engineering Meet Pipeline Editor, your one-stop shop for building a CI/CD pipeline
Published on: February 22, 2021
6 min read

Meet Pipeline Editor, your one-stop shop for building a CI/CD pipeline

The Pipeline Editor reduces the complexity of configuring your CI/CD pipelines.


This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-03-02.

In GitLab 13.8, we introduced the first iteration of the Pipeline Editor: a dedicated editor designed for authoring your CI/CD. It is your one-stop shop for everything you need to configure your CI/CD pipelines.

Why do we need a dedicated editor for pipelines?

GitLab's advanced syntax provides a high degree of customization for sophisticated and demanding CI/CD use cases. However, all of this power and flexibility comes with a fair bit of complexity. The Pipeline Editor helps you mitigate this challenge and serves as a single solution that groups all existing CI authoring features in a single location. It is our foundation, and we plan to build on it with enhancements in future iterations.

Getting started

In order for the pipeline editor to work, you'll first need to create a .gitlab-ci.yml file in your project. The .gitlab-ci.yml is a YAML file where you configure specific GitLab CI/CD instructions. Check out how we are working on improving the first-time experience of creating a .gilab-ci.yml file directly from the Pipeline Editor.

Continuous validation

Once you have created the .gitlab-ci.yml file and navigated to it in the Pipeline Editor, you can begin editing your configuration. Writing YAML can be error prone. No matter how technical or skilled you are, programming mistakes happen. Sometimes an indentation will be missed, the incorrect syntax is used, or the wrong keyword is selected, and that's OK! As you start authoring your pipeline, GitLab will inspect the pipeline configuration using our linting APIs and provide you with an indicator of whether your pipeline configuration is valid or not. We will continuously validate your pipeline without making any changes to your pipeline configuration, so you can have confidence in hitting "merge" and running your pipeline without any surprises.

Continuous validation of pipelines Continuous validation of your pipelines

Pipeline visualizer: Seeing is believing

It's practically impossible to envision what a pipeline should look like when you start writing from a blank YAML file. Luckily, GitLab provides you with a full pipeline view for every running pipeline. But, what if you want to visualize your pipeline before they begin to run? Well, you can do that now by navigating to the "Visualize" tab in the Pipeline Editor. You'll find an illustration that shows how your pipeline should look as you write it, similar to the linter, and GitLab will display the visual before making any commits, before running, or before altering your pipeline in any way.

In the visualization, we will group all your defined pipeline jobs by stages and add links between the jobs based on the needs relationships you've configured.

If we take a look at the example below, you can easily see that I've configured a three-stage pipeline, where the build stage has three jobs (step 1-3), and that step 4 needs steps 1 and 3.

Pipeline editor overview Pipeline visualizer

Here is what the YAML looks like:

image: alpine:latest

  - test
  - build
  - deploy
  script: exit 0
  stage: test
  script: echo testo
  stage: build
  script: echo testo
  stage: build
  script: echo testo
  stage: build
  needs: ['step1', 'step3']
  script: exit 0
  stage: deploy

View an expanded version of the CI/CD configuration

When configuring pipelines, you use keywords like 'include' and 'extends' often. These keywords help break down one long pipeline configuration file into multiple files, which increases readability and reduces duplication. Unfortunately, those keywords can make a pipeline configuration hard to follow. In some configurations, a pipeline configuration file can be mostly composed of a list of other included configuration files.

To make the configuration easier to follow, we've added the ability to view a version of your pipeline configuration with all of the 'includes' and 'extends' configurations merged together as a fourth tab in the Pipeline Editor. Now it's much easier to understand more complex pipeline flows and this simplifies the debugging process.

Pipeline configuration example:

pipeline configuration

The expanded version of the pipeline configuration:

expanded pipeline configuration


The CI lint helps you validate your pipeline configuration and provides you with additional information about it. That's why we've copied the existing CI linter (which was well hidden in our jobs page) to the Pipeline Editor as a third tab.

The linter provides you with detailed information about every job you've configured in your pipeline. For each job, it provides the before_script, after_script, and script fields, tags, environment names, branches it should run, and more…

If you look at the following example, just by looking at the linter tab you'll know that the prepare job:

  • Runs in the prepare stage
  • Contains before_script, script, and after_scripts fields
  • Runs only on master
  • Runs upon failure
  • Tag as production
  • Has the environment set to production


In this second example, you can see that the build job is a manual job that runs on all branches and is allowed to fail:

Manual build job

How the Pipeline Editor came about

Earlier this year, we decided to split continuous integration into two separate teams: Continuous Integration, which is responsible for improving the experience of running a CI/CD pipeline, and Pipeline Authoring, responsible for helping you author your pipeline. We've defined the Pipeline Authoring team goal as, "Making the authoring experience as easy as possible for both advanced and novice users."

Verify Groups

As a team, we realized that a dedicated authoring area is needed to achieve our ambitious roadmap – this is when the Pipeline Editor idea was formed.

Try out Pipeline Editor yourself

That's it! I hope you found this overview useful. To get started with GitLab CI, you can try out our hosted solution, or you can download GitLab Self-Managed and read its documentation for more in-depth coverage of the functionality.

If you are using our Pipeline Editor, we would love it if you leave us a note on our feedback issue! If you'd like to learn more about the upcoming features, feel free to read through the Pipeline Editor second iteration epic, and tag @dhershkovitch if you have any questions.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert