Markdown
English Deutsch

For beginners

What are pipelines?

A pipeline tests, versions, builds, and distributes your application after every push to main, and you start the last step to production yourself.

On this page

A pipeline is a chain of work steps that GitLab runs after every push: it checks your code, calculates a version number, builds the application, and brings it to the server or into the stores. Every generated repository comes with its pipeline in .gitlab-ci.yml; do not change it, not even to fix an error, because the platform maintains and overwrites it, and ask support for additional automation.

The stages of a pipeline

A pipeline consists of jobs in stages that run one after another; if a job fails, the pipeline stops there.

flowchart LR
  test["test"] --> version["update-version"]
  version --> build["build"]
  build --> publish["publish<br/>(automatic)"]
  publish --> release["release<br/>(manual)"]

In test, your code’s tests and checks run. In update-version, the pipeline calculates the version number from the commit messages; feat: raises the minor version, fix: marks a bug fix that also results in a new version. In build, the Docker image for backends and web apps or the app build for iOS and Android is produced. In publish, the pipeline automatically distributes the result to the dev server, to TestFlight, or to the internal test track of Google Play. release releases production or submits the app to the stores only when you click.

Viewing pipelines

In GitLab, open the repository and CI/CD → Pipelines; the list shows every pipeline with the triggering commit and the status running, passed, or failed. Clicking a pipeline shows its jobs by stage, clicking a job its log, where the error message is usually at the end.

Starting manual jobs

Jobs with a play button wait for you so that nothing goes to production or into the stores unnoticed.

  1. Open the pipeline of the main state you have checked on dev.
  2. Click the play button on the job you want, for example the production job.
  3. Follow the progress in the log. If there is no play button, an earlier job has usually failed or the pipeline is still running.

The path from a change to the pipeline is described in Save changes and publish, the version with branches and merge requests in Git workflow and deployment.