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

   This blog post is Unfiltered   

Pipeline Editor

In GitLab 13.8, we introduced the first iteration of the Pipeline Editor. The pipeline editor is 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. Find out what features are included and the benefits you'll get below.

Background

Earlier this year, GitLab decided to split the continuous integration into 2 separate teams - "Continuous integration" which is responsible to improve the experience of running a CI/CD pipeline, and "Pipeline Authoring" which is 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."

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

Pipeline Editor

In GitLab 13.8, we introduced the first iteration of the Pipeline Editor. The pipeline editor is 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. Find out what features are included and the benefits you'll get below.

Why do we need a dedicated editor?

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 the existing CI authoring features in a single location. It is our foundation, and on top, we plan to add enhancements in future iterations.

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 to create a .gilab-ci.yml file directly from the pipeline editor in this epic.

Continuous validation

Once you have created the .gitlab-ci.yml file and navigated it into 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 so you know if your pipeline configuration is valid or not. We will continuously validate your pipeline without making any changes to your pipeline configuration. You will have the confidence in hitting merge and running your pipeline without any surprises.

"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 what 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 3-stage pipeline, where the build stage has 3 jobs (step 1-3), and that step 4 needs steps 1 and 3.

Here is what the YAML looks like

image: alpine:latest
 
stages:
   - test
   - build
   - deploy
  
prepare:
   script: exit 0
   stage: test
  
step1:
   script: echo testo
   stage: build
step2:
   script: echo testo
   stage: build
step3:
   script: echo testo
   stage: build
  
step4:
   needs: ['step1', 'step3']
   script: exit 0
   stage: deploy

Lint

The CI lint helps you validate your pipeline configuration and provides you with additional information about your pipeline configuration. That is 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, you can see that the test job in the prepare stage has before, script and after, runs on master, upon failure, has a production and tag and environment

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

That's it! I hope you found this overview useful. To get started with GitLab CI, you can try out our hosted Gitlab.com solution, or you can download GitLab 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 2nd iteration epic, and tag @dhershkovitch if you have any questions.

from GitLab https://ift.tt/2Me9slD #GitLab #DevSecOps