Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Create a GitLab pipeline by adding a .gitlab-ci.yml file to your project’s repository root, defining jobs and their commands, and committing the file. GitLab creates a pipeline from that configuration; a runner must be available to execute the jobs.
What you need before creating a pipeline
- A GitLab project and Maintainer or Owner access, as required by GitLab’s first-pipeline tutorial.
- An active runner that can handle the jobs. GitLab.com users can use GitLab-provided instance runners; in other environments, ask your GitLab administrator whether a suitable runner is configured, or install and register GitLab Runner.
- A
.gitlab-ci.ymlconfiguration file in the repository root. That is the default location; project settings can instead point to a custom path, another project, or an external configuration URL.
Create and run a basic pipeline
- Open or clone your GitLab project. Make sure you can commit changes to the branch where you want the pipeline to run.
- Create
.gitlab-ci.ymlin the repository root. Add a build stage and a test stage, with one job in each:
stages:
- build
- test
build-job:
stage: build
script:
- echo "Build step"
test-job:
stage: test
script:
- echo "Test step"- Commit and push the file. GitLab reads the configuration and creates a pipeline for the relevant event, such as a branch push.
- Check the pipeline in GitLab. Open your project’s CI/CD pipelines page to see its status and jobs. A runner executes each job’s
scriptcommands; if no eligible runner is available, jobs cannot run.
The example uses two stages. Jobs in the same stage can run in parallel when runners are available; by default, GitLab proceeds to the next stage after jobs in the current stage succeed. For the complete first-pipeline walkthrough, see GitLab’s CI/CD quick start.
How the configuration controls execution
Jobs and stages
A job defines work for a runner, usually through its script commands. Stages group jobs and provide a simple order for the workflow—for example, build, test, then deploy. If you omit stages, GitLab’s documented default order is .pre, build, test, deploy, and .post. A job can select a stage with the stage keyword. See the CI/CD YAML reference.
Job rules and pipeline workflow rules
Use a job’s rules to decide whether that job is included in a pipeline. GitLab evaluates rules in order when creating the pipeline; the first match determines the result, and a job with no matching rule is not added. Use workflow: rules to control whether GitLab creates the pipeline at all. Workflow rules are evaluated before job rules, so a pipeline-level rule can prevent creation even if a job rule matches. See the YAML reference and workflow rules documentation.
#1 Best Overall
Dependencies with needs
Stages impose a barrier: ordinarily, the next stage waits for the current stage to finish successfully. Use needs when a job can start as soon as its specific dependencies finish, rather than waiting for all work in earlier stages. This can reduce waiting when parts of the pipeline are independent. If a needed job may be absent in some pipelines because of rules, GitLab documents needs:optional for that case. Keep dependency jobs and their inclusion rules aligned so a job does not require work that the pipeline omitted. See the YAML reference and needs documentation.
Choose how and when pipelines run
GitLab can create pipelines for events such as branch pushes, merge requests, and schedules, and pipelines can also be run manually. To include a job in a merge request pipeline, configure a rule that matches CI_PIPELINE_SOURCE == "merge_request_event". This condition belongs in .gitlab-ci.yml, in a job rule or a workflow rule, depending on whether you want to control one job or pipeline creation. See merge request pipeline documentation.
Rank #2
Validate the YAML before depending on it
Use GitLab’s CI Lint to check configuration syntax and logic, including included files. It can also simulate pipeline creation, which helps expose more involved problems with rules and needs. The pipeline editor checks syntax and visualizes stages, jobs, and dependency relationships. These tools are useful when a configuration parses but does not create the jobs or relationships you expected. See CI Lint documentation and pipeline editor documentation.
When to move beyond stages
For a small workflow with a straightforward build-test-deploy sequence, stages are usually the simplest design. Add needs when jobs should proceed as soon as their own dependencies finish. For a larger repository or work coordinated across projects, GitLab also supports parent-child pipelines and multi-project pipelines: parent-child pipelines split complex work within one project, while multi-project pipelines coordinate work across projects. See GitLab pipeline documentation and pipeline architecture documentation.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
