pipeline passed что значит gitlab
Как запустить несколько пайплайнов с помощью 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 есть графики пайплайнов для просмотра пайплайнов и их статусов.
Основы CI/CD на gitlab
Aug 22, 2019 · 5 min read
Gitlab предоставляет уникальную возможность получить одновременно бесплатный приватный репозиторий и бесплатный CI/CD из коробки в том же месте. Для сохранения баланса он конфигурируется не менее уникальным способом через конфиг-файл, который не так-то просто для понимания(я в первый раз вникала чересчур долго). В конце концов разобралась, и хочу поделиться.
Как это работает вообще все?
Настроить билды без этого файла, как, например, в тимсити или дженкинсе нельзя.
Ура, я хочу захостить свой фронтенд-проект на gitlab!
В отличие от простого gh-pages, где ты собираешь, что хочешь, и просто пушишь в репозиторий файл index.html, тут так поступить нельзя. Ну, то есть, в теории, можно, но автоматически ничего все равно работать не будет.
Как будет выглядеть в gitlab конфиг “типа как на gh-pages” (я предполагаю, что мы, как и с gh-pages уже собрали все в папку dist и запушили ее).
Главный секрет деплоя статики — положить все необходимое в папку public и отметить ее как артефакт.
И тут задумываемся — зачем собирать все локально, если можно делать это на машинах гитлаба, все равно же конфиг пишем. Это займет чуть больше времени, зато будет надежнее.
Все, мы разобрались с тем, как сделать, чтобы сайт собирался и деплоился, достаточно просто вносить изменения, пушить и он автоматически будет пересобираться и обновляться!
Теперь можно разобраться поподробнее в конфиге и придумать, какие еще возможности можно использовать
Этапы сборки
Конфиг “stage” — этап билда, по дефолту их три: build, test, deploy. Этапы всегда идут в четком порядке. Можно не указывать ничего, тогда запустится на этапе test.
Разберемся, что это такое и как использовать это во благо. Если подумать, этапов работы с кодом у нас и правда в целом три: собрать, протестировать(убедиться, что это можно деплоить), задеплоить. И если один из них упал, остальные запускать нет необходимости.
По этому принципу делает и гитлаб:
Особенность конфига гитлаба в том, что мы не идем вроде как логично, объявляя этапы и наполняя их задачами, а, наоборот, каждой задаче указываем, на каком она этапе. Этапы, конечно же, можно создать любые, не ограничиваясь стандартными.
Например кусочек конфига для скриншота выше:
Стоит поменять порядок этапов в конфиге, и они начнут выполняться в другом порядке.
cache
Билды обычно идут дольше, чем хотелось бы. Первое, что приходит в голову — это что же, каждый раз скачивать зависимости? Это можно улучшить!
В конфиг задачи достаточно добавить вот такое:
$
Гитлаб предоставляет много разных переменных, которые можно использовать здесь. Кешировать node_modules наиболее эффективно по веткам, хотя можно шерить кеш на весь репозиторий. Или вообще написать хитрое условие.
Артефакты
В конфиге выше написано:
Артефакты работают так: файлы, лежащие по указанным путям, в конце каждой джобы загружаются на сервер гитлаба и скачиваются в начале каждой джобы следующего этапа.
Погодите, звучит как кеш! В чем разница?
Кеш, исходя из названия, нужен для того, чтобы что-то временно хранить для ускорения сборки. Кстати, исходя из его предназначния, гитлаб не гарантирует то, что кеш найдется, он вполне себе может потеряться.
Я описала два глобальных отличия, есть еще несколько, их можно найти здесь.
Но в итоге непонятно: как тут добавление артефактов позволяет деплоить pages, и когда вообще нужно их использовать?
Все, базовые основы CD на gitlab вы знаете, теперь можно хостить и деплоить код втайне от подписчиков на гитхабе (а если не хотите и гитлаб светить, то приватные репозитории + heroku в помощь!).
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.
Multi-project pipelines
Moved to GitLab Free in 12.8.
You can set up GitLab CI/CD across multiple projects, so that a pipeline in one project can trigger a pipeline in another project. You can visualize the entire pipeline in one place, including all cross-project interdependencies.
For example, you might deploy your web application from three different projects in GitLab. Each project has its own build, test, and deploy process. With multi-project pipelines you can visualize the entire pipeline, including all build and test stages for all three projects.
Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those with a microservices architecture. Learn more in the Cross-project Pipeline Triggering and Visualization demo at GitLab@learn, in the Continuous Integration section.
If you have a public project that can trigger downstream pipelines in a private project, make sure there are no confidentiality problems.
Create multi-project pipelines
Moved to GitLab Free in 12.8.
You can view the status for the pipeline, or you can display the downstream pipeline’s status instead.
The user that creates the upstream pipeline must be able to create pipelines in the downstream project ( my/deployment ) too. If the downstream project is not found, or the user does not have permission to create a pipeline there, the staging job is marked as failed.
Trigger job configuration keywords
Specify a downstream pipeline branch
You can specify a branch name for the downstream pipeline to use. GitLab uses the commit on the head of the branch to create the downstream pipeline.
Pipelines triggered on a protected branch in a downstream project use the role of the user that ran the trigger job in the upstream project. If the user does not have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See pipeline security for protected branches.
Pass CI/CD variables to a downstream pipeline by using the variables keyword
Sometimes you might want to pass CI/CD variables to a downstream pipeline. You can do that by using the variables keyword, just like you would for any other job.
The ENVIRONMENT variable is passed to every job defined in a downstream pipeline. It is available as a variable when GitLab Runner picks a job.
In the following configuration, the MY_VARIABLE variable is passed to the downstream pipeline that is created when the trigger-downstream job is queued. This is because trigger-downstream job inherits variables declared in global variables blocks, and then we pass these variables to a downstream pipeline.
You can stop global variables from reaching the downstream pipeline by using the inherit:variables keyword. In this example, the MY_GLOBAL_VAR variable is not available in the triggered pipeline:
You might want to pass some information about the upstream pipeline using, for example, predefined variables. In order to do that, you can use interpolation to pass any variable. For example:
In this scenario, the UPSTREAM_BRANCH variable with a value related to the upstream pipeline is passed to the downstream-job job. It is available in the context of all downstream builds.
Upstream pipelines take precedence over downstream ones. If there are two variables with the same name defined in both upstream and downstream projects, the ones defined in the upstream project take precedence.
Pass CI/CD variables to a downstream pipeline by using variable inheritance
You can pass variables to a downstream pipeline with dotenv variable inheritance and cross project artifact downloads.
Trigger the downstream pipeline.
Use rules or only / except with multi-project pipelines
If you use only/except to control job behavior, use the pipelines keyword.
Mirror status of a triggered pipeline in the trigger job
Mirror status from upstream pipeline
You can mirror the pipeline status from an upstream pipeline to a bridge job by using the needs:pipeline keyword. The latest pipeline status from the default branch is replicated to the bridge job.
Create multi-project pipelines by using the API
Moved to GitLab Free in 12.4.
When you use the CI_JOB_TOKEN to trigger pipelines, GitLab recognizes the source of the job token. The pipelines become related, so you can visualize their relationships on pipeline graphs.
These relationships are displayed in the pipeline graph by showing inbound and outbound connections for upstream and downstream pipeline dependencies.
Trigger a pipeline when an upstream project is rebuilt
You can trigger a pipeline in your project whenever a pipeline finishes for a new tag in a different project.
Any pipelines that complete successfully for new tags in the subscribed project now trigger a pipeline on the current project’s default branch. The maximum number of upstream pipeline subscriptions is 2 by default, for both the upstream and downstream projects. On self-managed instances, an administrator can change this limit.
Multi-project pipeline visualization
When you configure GitLab CI/CD for your project, you can visualize the stages of your jobs on a pipeline graph.
In the merge request, on the Pipelines tab, multi-project pipeline mini-graphs are displayed. They expand and are shown adjacent to each other when hovering (or tapping on touchscreen devices).
Customize pipeline configuration
You can customize how pipelines run for your project.
Change which users can view your pipelines
Auto-cancel redundant pipelines
Use the interruptible keyword to indicate if a running job can be cancelled before it completes.
Skip outdated deployment jobs
Your project may have multiple concurrent deployment jobs that are scheduled to run in the same time frame.
This can lead to a situation where an older deployment job runs after a newer one, which may not be what you want.
Older deployment jobs are skipped when a new deployment starts.
For more information, see Deployment safety.
Retry outdated jobs
A deployment job can fail because a newer one has run. If you retry the failed deployment job, the environment could be overwritten with older source code. If you click Retry, a modal warns you about this and asks for confirmation.
For more information, see Deployment safety.
Specify a custom CI/CD configuration file
Custom CI/CD configuration file examples
Then other users and projects can access the configuration file without being able to edit it.
Choose the default Git strategy
Limit the number of changes fetched during clone
Set a limit for how long jobs can run
Jobs that exceed the timeout are marked as failed.
You can override this value for individual runners.
Add test coverage results to a merge request
You can use https://rubular.com to test your regex. The regex returns the last match found in the output.
If the pipeline succeeds, the coverage is shown in the merge request widget and in the jobs table. If multiple jobs in the pipeline have coverage reports, they are averaged.
Test coverage examples
Use this regex for commonly used test tools.
View code coverage history
The historic data for each job is listed in the dropdown above the graph.
Coverage check approval rule
You can implement merge request approvals to require approval by selected users or a group when merging a merge request would cause the project’s test coverage to decline.
Remove color codes from code coverage
Some test coverage tools output with ANSI color codes that aren’t parsed correctly by the regular expression. This causes coverage parsing to fail.
Some coverage tools don’t provide an option to disable color codes in the output. If so, pipe the output of the coverage tool through a small one line script that strips the color codes off.
Pipeline badges
Pipeline badges indicate the pipeline status and a test coverage value for your project. These badges are determined by the latest successful pipeline.
View the code for the pipeline status and coverage reports badges
Pipeline status badge
You can access a pipeline status badge image by using the following link:
Display only non-skipped status
Test coverage report badge
You can define the regular expression for the coverage report that each job log is matched against. This means that each job in the pipeline can have the test coverage percentage value defined.
To access the test coverage badge, use the following link:
To get the coverage report from a specific job, add the job=coverage_job_name parameter to the URL. For example, the following Markdown code embeds the test coverage report badge of the coverage job in your README.md :
Test coverage report badge colors and limits
Badge styles
Pipeline badges can be rendered in different styles by adding the style=style_name parameter to the URL. Two styles are available:
Flat square (Introduced in GitLab 11.8):
Custom badge text
The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the key_text=custom_text and key_width=custom_key_width parameters to the URL: