pipeline passed что значит gitlab

GitLab

CI/CD pipelines (FREE)

NOTE: Watch the «Mastering continuous software development» webcast to see a comprehensive demo of a GitLab CI/CD pipeline.

Pipelines are the top-level component of continuous integration, delivery, and deployment.

Jobs are executed by runners. Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.

If all jobs in a stage succeed, the pipeline moves on to the next stage.

If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early.

In general, pipelines are executed automatically and require no intervention once created. However, there are also times when you can manually interact with a pipeline.

A typical pipeline might consist of four stages, executed in the following order:

NOTE: If you have a mirrored repository that GitLab pulls from, you may need to enable pipeline triggering in your project’s Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.

Types of pipelines

Pipelines can be configured in many different ways:

Configure a pipeline

Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.

For a list of configuration options in the CI pipeline file, see the GitLab CI/CD Pipeline Configuration Reference.

You can also configure specific aspects of your pipelines through the GitLab UI. For example:

Ref Specs for Runners

When a runner picks a pipeline job, GitLab provides that job’s metadata. This includes the Git refspecs, which indicate which ref (branch, tag, and so on) and commit (SHA1) are checked out from your project repository.

This table lists the refspecs injected for each pipeline type:

The refs refs/heads/ and refs/tags/ exist in your project repository. GitLab generates the special ref refs/pipelines/ during a running pipeline job. This ref can be created even after the associated branch or tag has been deleted. It’s therefore useful in some features such as automatically stopping an environment, and merge trains that might run pipelines after branch deletion.

View pipelines

You can find the current and historical pipeline runs under your project’s CI/CD > Pipelines page. You can also access pipelines for a merge request by navigating to its Pipelines tab.

Click a pipeline to open the Pipeline Details page and show the jobs that were run for that pipeline. From here you can cancel a running pipeline, retry jobs on a failed pipeline, or delete a pipeline.

Starting in GitLab 13.0, you can filter the pipeline list by:

Run a pipeline manually

Pipelines can be manually executed, with predefined or manually-specified variables.

You might do this if the results of a pipeline (for example, a code build) are required outside the normal operation of the pipeline.

To execute a pipeline manually:

The pipeline now executes the jobs as configured.

Prefill variables in manual pipelines

You can use the value and description keywords to define variables that are prefilled when running a pipeline manually.

The description is displayed below the variable. It can be used to explain what the variable is used for, what the acceptable values are, and so on:

Run a pipeline by using a URL query string

The format of the pipelines/new URL is:

The following parameters are supported:

Add manual interaction to your pipeline

Manual actions, configured using the when:manual keyword, allow you to require manual interaction before moving forward in the pipeline.

You can do this straight from the pipeline graph. Just click the play button to execute that particular job.

For example, your pipeline might start automatically, but it requires manual action to deploy to production. In the example below, the production stage has a job with a manual action.

Start multiple manual actions in a stage

Multiple manual actions in a single stage can be started at the same time using the «Play all manual» button. After you click this button, each individual manual action is triggered and refreshed to an updated status.

This functionality is only available:

Delete a pipeline

Users with owner permissions in a project can delete a pipeline by clicking on the pipeline in the CI/CD > Pipelines to get to the Pipeline Details page, then using the Delete button.

WARNING: Deleting a pipeline expires all pipeline caches, and deletes all related objects, such as builds, logs, artifacts, and triggers. This action cannot be undone.

Pipeline quotas

Each user has a personal pipeline quota that tracks the usage of shared runners in all personal projects. Each group has a usage quota that tracks the usage of shared runners for all projects created within the group.

When a pipeline is triggered, regardless of who triggered it, the pipeline quota for the project owner’s namespace is used. In this case, the namespace can be the user or group that owns the project.

How pipeline duration is calculated

Total running time for a given pipeline excludes retries and pending (queued) time.

A simple example is:

Visually, it can be viewed as:

The union of A, B, and C is (1, 4) and (6, 7). Therefore, the total running time is:

How pipeline quota usage is calculated

Pipeline quota usage is calculated as the sum of the duration of each individual job. This is slightly different to how pipeline duration is calculated. Pipeline quota usage doesn’t consider any overlap of jobs running in parallel.

For example, a pipeline consists of the following jobs:

The pipeline quota usage is the sum of each job’s duration. In this example, 8 runner minutes would be used, calculated as: 3 + 3 + 2.

Pipeline security on protected branches

A strict security model is enforced when pipelines are executed on protected branches.

The following actions are allowed on protected branches only if the user is allowed to merge or push on that specific branch:

Variables marked as protected are accessible only to jobs that run on protected branches, preventing untrusted users getting unintended access to sensitive information like deployment credentials and tokens.

Runners marked as protected can run jobs only on protected branches, preventing untrusted code from executing on the protected runner and preserving deployment keys and other credentials from being unintentionally accessed. In order to ensure that jobs intended to be executed on protected runners do not use regular runners, they must be tagged accordingly.

Visualize pipelines

Pipelines can be complex structures with many sequential and parallel jobs.

To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines and their statuses.

Pipeline graphs can be displayed as a large graph or a miniature representation, depending on the page you access the graph from.

GitLab capitalizes the stages’ names in the pipeline graphs.

View full pipeline graph

The pipeline details page displays the full pipeline graph of all the jobs in the pipeline.

You can group the jobs by:

Stage, which arranges jobs in the same stage together in the same column.

Job dependencies, which arranges jobs based on their needs dependencies.

Multi-project pipeline graphs help you visualize the entire pipeline, including all cross-project inter-dependencies. (PREMIUM)

View job dependencies in the pipeline graph

This in-development feature might not be available for your use. There can be risks when enabling features still in development. Refer to this feature’s version history for more details.

You can arrange jobs in the pipeline graph based on their needs dependencies.

Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.

For example, build-job2 depends only on jobs in the first column, so it displays in the second column from the left. deploy-job2 depends on jobs in both the first and second column and displays in the third column:

To add lines that show the needs relationships between jobs, select the Show dependencies toggle. These lines are similar to the needs visualization:

To see the full needs dependency tree for a job, hover over it:

Enable or disable job dependency view (FREE SELF)

The job dependency view is deployed behind a feature flag that is enabled by default. GitLab administrators with access to the GitLab Rails console can disable it.

Pipeline mini graphs

Pipeline mini graphs take less space and can tell you at a quick glance if all jobs passed or something failed. The pipeline mini graph can be found when you navigate to:

Pipeline mini graphs allow you to see all related jobs for a single commit and the net result of each stage of your pipeline. This allows you to quickly see what failed and fix it.

Pipeline mini graphs only display jobs by stage.

Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs.

Mini graph	Mini graph expanded

Pipeline success and duration charts

Pipeline analytics are available on the CI/CD Analytics page.

Pipeline badges

Pipeline status and test coverage report badges are available and configurable for each project. For information on adding pipeline badges to projects, see Pipeline badges.

Pipelines API

GitLab provides API endpoints to:

Источник

Как запустить несколько пайплайнов с помощью GitLab CI/CD

Запуск и визуализация пайплайнов при настройке GitLab CI/CD для нескольких проектов.

Непрерывная интеграция (CI) — это практика автоматизации сборки и тестирования кода до его слияния с основной веткой. Она позволяет разработчикам вливать код довольно часто и рано, снижая при этом риск внесения новых ошибок в главный репозиторий исходного кода.

Хотя CI проверяет, что новый код не сломается при интеграции с другим кодом в том же репо, прохождение всех тестов на этом репо — это только первый шаг. После запуска CI в коде важно развернуть и запустить тесты в реальной среде. Переход от CI к непрерывной доставке и деплою (CD) является следующим шагом к “взрослому” DevOps. Развертывание и последующее повторное тестирование позволяют тестировать код одного проекта вместе с другими компонентами и сервисами, которые, возможно, управляются другими проектами.

Зачем мне нужно убедиться, что мой код работает с другими компонентами?

Хорошим примером может служить архитектура микросервисов. Обычно микросервисы управляются в разных проектах, где каждый микросервис имеет свой собственный репозиторий с пайплайном. Кроме того, очень часто каждая команда разработчиков несёт ответственность за отдельные микросервисы и конфигурации пайплайнов. Как программист, вы возможно захотите убедиться, что изменения в вашем коде не нарушают функциональность зависимых от него микросервисов. Поэтому вы можете запускать тесты на них дополнительно к тестам для вашего проекта.

Пайплайн кросс-проекта

При запуске пайплайна проекта, вам также нужно будет запустить кросс-проектные пайплайны, которые в конечном итоге развернут и протестируют последнюю версию всех зависимых микросервисов. Для достижения этой цели вам нужен простой, гибкий и удобный способ запуска других пайплайнов в рамках CI вашего проекта. GitLab CI/CD предлагает легкий путь запуска кросс-проектного пайплайна путем добавления специального задания в файл конфигурации CI.

GitLab CI/CD конфигурационный файл

Добавление job для запуска кросс-проектного пайплайна

Начиная с GitLab 11.8, GitLab предоставляет новый синтаксис конфигурации CI/CD для запуска кросс-проектных пайплайнов, его можно найти в правилах конфигурации пайплайна. Следующий код иллюстрирует настройку bridge job для запуска нисходящего пайплайна:

В приведенном выше примере, как только deploy job (задача развертывания) на этапе деплоя выполнится успешно, запустится задание для Android bridge. Его первоначальный статус будет в ожидании. GitLab создаст нисходящий пайплайн в проекте mobile/android, и, как только он будет создан, Android job выполнится успешно. В этом случае mobile/android является полным путем к этому проекту.

Пользователь, создавший вышестоящий пайплайн, должен иметь права доступа к нижестоящему проекту (в данном случае mobile / android). Если нижестоящий проект не может быть найден или у пользователя нет прав доступа для создания там пайплайна, Android job получит статус failed.

Обзор графиков от восходящего до нижестоящего пайплайна

GitLab CI/CD позволяет визуализировать конфигурацию пайплайна. На приведенном ниже рисунке этапы сборки, тестирования и деплоя являются частями восходящего (upstream) проекта. Как только deploy job выполнено успешно, четыре кросс-проекта будут запущены параллельно, и вы сможете перейти к ним, щелкнув на одну из нисходящих (downstream) job.

На приведенном ниже рисунке виден нисходящий пайплайн «Сервис — Финансы». Теперь можно прокрутить влево к восходящему пайплайну, прокрутить вправо назад к нисходящему или выбрать другой нисходящий пайплайн.

Определение ветки нижестоящего пайплайна

Можно указать имя ветки, которое будет использовать нисходящий пайплайн:

Используйте ключевое слово проекта, чтобы указать полный путь к нисходящему проекту. Используйте ключевое слово branch, чтобы определить имя ветки. GitLab будет использовать коммит, который в данный момент находится в HEAD ветки при создании нисходящего пайплайна.

Передача переменных в нисходящий пайплайн

Когда-нибудь вам возможно захочется передать переменные в нисходящий пайплайн. Вы можете сделать это с помощью ключевых слов для переменных, как и при определении обычной job.

Переменная ENVIRONMENT будет передаваться каждой job, определенной в нисходящем пайплайне. Она будет доступна в качестве переменной среды каждый раз, когда GitLab Runner выбирает job.

Итого о кросс-проектном пайплайне

Пайплайны могут быть сложными структурами с множеством последовательных и параллельных задач, и, как мы только что узнали, иногда они могут запускать нисходящие пайплайны. Чтобы упростить понимание потока пайплайна, включая нисходящие пайплайны, в GitLab есть графики пайплайнов для просмотра пайплайнов и их статусов.

Источник

Pipelines for merge requests

In a basic configuration, GitLab runs a pipeline each time changes are pushed to a branch.

If you want the pipeline to run jobs only on commits associated with a merge request, you can use pipelines for merge requests.

These pipelines are labeled as detached in the UI, and they do not have access to protected variables. Otherwise, these pipelines are the same as other pipelines.

If you use this feature with merge when pipeline succeeds, pipelines for merge requests take precedence over other pipelines.

Prerequisites

Configure pipelines for merge requests

Use rules to run pipelines for merge requests

GitLab recommends that you use the rules keyword, which is available in workflow:rules templates.

Use only or except to run pipelines for merge requests

Exclude specific jobs

In this example, you don’t have to add the only rule to all of your jobs to make them always run. You can use this format to set up a Review App, which helps to save resources.

Exclude specific branches

Because of this difference, the following configuration does not work as expected:

Run pipelines in the parent project for merge requests from a forked project

If a pipeline runs in a fork, a fork badge appears for the pipeline in the merge request.

Sometimes parent project members want the pipeline to run in the parent project. They may want to ensure that the post-merge pipeline passes in the parent project. For example, a fork project could try to use a corrupted runner that doesn’t execute test scripts properly, but reports a passed pipeline. Reviewers in the parent project could mistakenly trust the merge request because it passed a faked pipeline.

Parent project members with at least the Developer role can create pipelines in the parent project for merge requests from a forked project. In the merge request, go to the Pipelines tab and select Run pipeline.

Predefined variables available for pipelines for merge requests

When you use pipelines for merge requests, additional predefined variables are available to the CI/CD jobs. These variables contain information from the associated merge request, so that you can integrate your job with the GitLab Merge Request API.

Troubleshooting

Two pipelines created when pushing to a merge request

In GitLab 13.7 and later, you can add workflow:rules to switch from branch pipelines to merge request pipelines. After a merge request is open on the branch, the pipeline switches to a merge request pipeline.

Two pipelines created when pushing an invalid CI configuration file

Pushing to a branch with an invalid CI configuration file can trigger the creation of two types of failed pipelines. One pipeline is a failed merge request pipeline, and the other is a failed branch pipeline, but both are caused by the same invalid configuration.

Источник

CI/CD pipelines

Pipelines are the top-level component of continuous integration, delivery, and deployment.

Jobs are executed by runners. Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.

If all jobs in a stage succeed, the pipeline moves on to the next stage.

If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early.

In general, pipelines are executed automatically and require no intervention once created. However, there are also times when you can manually interact with a pipeline.

Types of pipelines

Configure a pipeline

For a list of configuration options in the CI pipeline file, see the GitLab CI/CD Pipeline Configuration Reference.

Ref specs for runners

When a runner picks a pipeline job, GitLab provides that job’s metadata. This includes the Git refspecs, which indicate which ref (branch, tag, and so on) and commit (SHA1) are checked out from your project repository.

This table lists the refspecs injected for each pipeline type:

The refs refs/heads/ and refs/tags/ exist in your project repository. GitLab generates the special ref refs/pipelines/ during a running pipeline job. This ref can be created even after the associated branch or tag has been deleted. It’s therefore useful in some features such as automatically stopping an environment, and merge trains that might run pipelines after branch deletion.

View pipelines

You can find the current and historical pipeline runs under your project’s CI/CD > Pipelines page. You can also access pipelines for a merge request by navigating to its Pipelines tab.

Click a pipeline to open the Pipeline Details page and show the jobs that were run for that pipeline. From here you can cancel a running pipeline, retry jobs on a failed pipeline, or delete a pipeline.

Starting in GitLab 14.2, you can change the pipeline column to display the pipeline ID or the pipeline IID.

If you use VS Code to edit your GitLab CI/CD configuration, the GitLab Workflow VS Code extension helps you validate your configuration and view your pipeline status.

Run a pipeline manually

Pipelines can be manually executed, with predefined or manually-specified variables.

You might do this if the results of a pipeline (for example, a code build) are required outside the normal operation of the pipeline.

The pipeline now executes the jobs as configured.

Prefill variables in manual pipelines

You can use the value and description keywords to define pipeline-level (global) variables that are prefilled when running a pipeline manually.

The description is displayed next to the variable. It can be used to explain what the variable is used for, what the acceptable values are, and so on:

You cannot set job-level variables to be pre-filled when you run a pipeline manually.

Run a pipeline by using a URL query string

The format of the pipelines/new URL is:

Add manual interaction to your pipeline

Manual jobs, allow you to require manual interaction before moving forward in the pipeline.

You can do this straight from the pipeline graph. Just click the play button to execute that particular job.

For example, your pipeline can start automatically, but require a manual action to deploy to production. In the example below, the production stage has a job with a manual action:

Start multiple manual actions in a stage

Multiple manual actions in a single stage can be started at the same time using the “Play all manual” button. After you click this button, each individual manual action is triggered and refreshed to an updated status.

Skip a pipeline

Alternatively, if you are using Git 2.10 or later, use the ci.skip Git push option. The ci.skip push option does not skip merge request pipelines.

Delete a pipeline

Users with the Owner role in a project can delete a pipeline by clicking on the pipeline in the CI/CD > Pipelines to get to the Pipeline Details page, then using the Delete button.

Quotas of CI/CD minutes

Each user has a personal pipeline quota that tracks the usage of shared runners in all personal projects. Each group has a quota of CI/CD minutes that tracks the usage of shared runners for all projects created within the group.

When a pipeline is triggered, regardless of who triggered it, the quota of CI/CD minutes for the project owner’s namespace is used. In this case, the namespace can be the user or group that owns the project.

How pipeline duration is calculated

Total running time for a given pipeline excludes retries and pending (queued) time.

Visually, it can be viewed as:

The union of A, B, and C is (1, 4) and (6, 7). Therefore, the total running time is:

How pipeline quota usage is calculated

Pipeline quota usage is calculated as the sum of the duration of each individual job. This is slightly different to how pipeline duration is calculated. Pipeline quota usage doesn’t consider any overlap of jobs running in parallel.

The pipeline quota usage is the sum of each job’s duration. In this example, 8 runner minutes would be used, calculated as: 3 + 3 + 2.

Pipeline security on protected branches

A strict security model is enforced when pipelines are executed on protected branches.

Variables marked as protected are accessible only to jobs that run on protected branches, preventing untrusted users getting unintended access to sensitive information like deployment credentials and tokens.

Runners marked as protected can run jobs only on protected branches, preventing untrusted code from executing on the protected runner and preserving deployment keys and other credentials from being unintentionally accessed. In order to ensure that jobs intended to be executed on protected runners do not use regular runners, they must be tagged accordingly.

Visualize pipelines

Pipelines can be complex structures with many sequential and parallel jobs.

To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines and their statuses.

Pipeline graphs can be displayed as a large graph or a miniature representation, depending on the page you access the graph from.

GitLab capitalizes the stages’ names in the pipeline graphs.

View full pipeline graph

The pipeline details page displays the full pipeline graph of all the jobs in the pipeline.

You can group the jobs by:

Stage, which arranges jobs in the same stage together in the same column:

Job dependencies, which arranges jobs based on their needs dependencies.

Multi-project pipeline graphs help you visualize the entire pipeline, including all cross-project inter-dependencies.

View job dependencies in the pipeline graph

You can arrange jobs in the pipeline graph based on their needs dependencies.

Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.

For example, test-job1 depends only on jobs in the first column, so it displays in the second column from the left. deploy-job1 depends on jobs in both the first and second column and displays in the third column:

To add lines that show the needs relationships between jobs, select the Show dependencies toggle. These lines are similar to the needs visualization:

To see the full needs dependency tree for a job, hover over it:

Pipeline mini graphs

Pipeline mini graphs allow you to see all related jobs for a single commit and the net result of each stage of your pipeline. This allows you to quickly see what failed and fix it.

Pipeline mini graphs only display jobs by stage.

Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs.

Mini graph	Mini graph expanded

Pipeline success and duration charts

Pipeline analytics are available on the CI/CD Analytics page.

Pipeline badges

Pipeline status and test coverage report badges are available and configurable for each project. For information on adding pipeline badges to projects, see Pipeline badges.

Pipelines API

Источник