A pipeline is the automation GitLab runs after every push: it builds your application, assigns versions, and deploys. Every generated repository comes with its pipeline fully configured – you don’t have to (and shouldn’t) change the .gitlab-ci.yml.
Structure: stages and jobs
A pipeline consists of jobs, grouped into stages that run one after another. Simplified:
flowchart LR test["test"] --> version["update-version"] version --> build["build"] build --> publish["publish<br/>(automatic)"] publish --> release["release<br/>(manual)"]
| Stage | What happens |
|---|---|
test |
Tests and checks of your code |
update-version |
Compute the new version number from the commits (feat: bumps the minor version) |
build |
Produce the Docker image or app build |
publish |
Distribute automatically: dev server, TestFlight, Internal Track |
release |
Manual release: production or store submission |
Viewing pipelines
In GitLab, open your repository → CI/CD → Pipelines. You see every pipeline with its status (running, passed, failed) and can click any job to read its log – the first place to look when something fails.
Starting manual jobs
Some jobs deliberately don’t start automatically – e.g. publish-docker-prod (prod deployment) or release-ios (store submission):
- Open the pipeline of the desired
mainstate. - Click the play button (▶) on the job.
- The job starts; follow the progress in the log.
Warning
Don’t change the
.gitlab-ci.yml files of your repositories – the platform manages and updates them. For custom automation, talk to support.See also
- Git workflow & deployment – which job runs when.
- Publishing apps – the app-specific jobs.