Gitlab - 3.3.4 whriting of the first pipeline

This lesson walks through writing your very first GitLab CI/CD pipeline. Two prerequisites: first, the application code must already be hosted in a Git repository (we have one). Second, you need a .gitlab-ci.yml file at the root of the repository. That YAML file defines the structure and order of your jobs, the scripts to run, dependencies, the tests to execute before deployment, the deployment target, and so on. In short, it defines your full pipeline end-to-end with step-by-step instructions.

Creating .gitlab-ci.yml from the GitLab UI

You can create the YAML file from your local system and push it to GitLab the same way we did with hello.py, or directly from the GitLab UI. The second option is easier for now. From the project dashboard, select a branch, click New file, and name it exactly .gitlab-ci.yml — the file name matters because GitLab only looks for this name to detect a pipeline (unless changed in project settings). From the file template dropdown you could pick a starter, but we will write ours from scratch.

Defining a single job

Every pipeline configuration starts by defining at least one job. A job is mandatory, and it starts with its name. Inside it, the stage keyword is optional — if not specified, GitLab places the job in the default test stage. The mandatory script keyword lists the commands to execute. Here is the minimal pipeline we will use:

job to run code:
  stage: test
  script:
    - python hello.py

We defined a single job that simply executes python hello.py. In real projects you typically define many jobs — almost unlimited — and we will see more of them in the next sections.

Committing and watching the pipeline run

With the pipeline defined, commit the file targeting the dev1 branch and confirm. As soon as GitLab notices a .gitlab-ci.yml in the repository, it starts running the pipeline automatically — no manual trigger required. Open the CI/CD section: the pipeline status is running.

The pipelines list page shows every pipeline, its status, who triggered it, etc., with a search bar to filter by author, branch, tag or status. On the right you can see how long each pipeline ran. Clicking a pipeline opens its details. Because pipelines can become complex graphs of sequential and parallel jobs, GitLab provides a visual graph view. Our pipeline has a single block — job to run code — but as you add jobs they will appear here in the order defined in your YAML. That is your first running pipeline. See you in the next video.