Tutorial: Create and run your first GitLab CI/CD pipeline

 This tutorial shows you how to configure and run your first CI/CD pipeline in GitLab.

Prerequisites

Before you start, make sure you have:

  • A project in GitLab that you would like to use CI/CD for.
  • The Maintainer or Owner role for the project.

If you don’t have a project, you can create a public project for free on https://gitlab.com.

Steps

To create and run your first pipeline:

  1. Ensure you have runners available to run your jobs.

    If you’re using GitLab.com, you can skip this step. GitLab.com provides instance runners for you.

  2. Create a .gitlab-ci.yml file at the root of your repository. This file is where you define the CI/CD jobs.

When you commit the file to your repository, the runner runs your jobs. The job results are displayed in a pipeline.

Ensure you have runners available

In GitLab, runners are agents that run your CI/CD jobs.

To view available runners:

  • Go to Settings > CI/CD and expand Runners.

As long as you have at least one runner that’s active, with a green circle next to it, you have a runner available to process your jobs.

If you don’t have a runner

If you don’t have a runner:

  1. Install GitLab Runner on your local machine.
  2. Register the runner for your project. Choose the shell executor.

When your CI/CD jobs run, in a later step, they will run on your local machine.

Create a .gitlab-ci.yml file

Now create a .gitlab-ci.yml file. It is a YAML file where you specify instructions for GitLab CI/CD.

In this file, you define:

  • The structure and order of jobs that the runner should execute.
  • The decisions the runner should make when specific conditions are encountered.

To create a .gitlab-ci.yml file:

  1. On the left sidebar, select Code > Repository.

  2. Above the file list, select the branch you want to commit to. If you’re not sure, leave master or main. Then select the plus icon () and New file:

    New file

  3. For the Filename, type .gitlab-ci.yml and in the larger window, paste this sample code:

    build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
  environment: production

    This example shows four jobs: build-job, test-job1, test-job2, and deploy-prod. The comments listed in the echo commands are displayed in the UI when you view the jobs. The values for the predefined variables $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH are populated when the jobs run.

  4. Select Commit changes.

The pipeline starts and runs the jobs you defined in the .gitlab-ci.yml file.

View the status of your pipeline and jobs

Now take a look at your pipeline and the jobs within.

  1. Go to Build > Pipelines. A pipeline with three stages should be displayed:

    Three stages

  2. View a visual representation of your pipeline by selecting the pipeline ID:

    Pipeline graph

  3. View details of a job by selecting the job name. For example, deploy-prod:

    Job details

You have successfully created your first CI/CD pipeline in GitLab. Congratulations!

Now you can get started customizing your .gitlab-ci.yml and defining more advanced jobs.

.gitlab-ci.yml tips

Here are some tips to get started working with the .gitlab-ci.yml file.

For the complete .gitlab-ci.yml syntax, see the full CI/CD YAML syntax reference.

  • Use the pipeline editor to edit your .gitlab-ci.yml file.
  • Each job contains a script section and belongs to a stage:
  • You can set additional configuration to customize how your jobs and stages perform:
    • Use the rules keyword to specify when to run or skip jobs. The only and except legacy keywords are still supported, but can’t be used with rules in the same job.
    • Keep information across jobs and stages persistent in a pipeline with cache and artifacts. These keywords are ways to store dependencies and job output, even when using ephemeral runners for each job.
    • Use the default keyword to specify additional configurations that are applied to all jobs. This keyword is often used to define before_script and after_script sections that should run on every job.

Comments

Post a Comment

Popular posts from this blog

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources and services.
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed without them. If these are not fulfilled, the project is con
Read more

Kubernetes

  Using containers to host applications and other processes has gone mainstream. As more and more workload is moved into containers, management systems are needed to handle the demands of containerized applications at scale. One of the most popular options for managing  container-based workload is Kubernetes . Kubernetes combines container management automation with an extensible API to create a cloud-native application management powerhouse. At its core, Kubernetes manages the placement of pods, which can consist of one or more containers, on a Kubernetes cluster node. Additionally, if one of these pods crashes, Kubernetes can create a new instance of it. If a cluster node is removed, Kubernetes can move any affected workload to a different node in the cluster. On top of that, Kubernetes pods can be scaled to provide more or less throughput to meet scale demands and these scale operations can be triggered manually or automatically using Kuberentes horizontal pod auto-scaling. Finally,
Read more