2019-10-12 21:52:04 +05:30
---
2020-06-23 00:09:42 +05:30
stage: Verify
2021-09-04 01:27:46 +05:30
group: Pipeline Authoring
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2019-10-12 21:52:04 +05:30
type: reference
---
2021-11-11 11:23:49 +05:30
# Directed Acyclic Graph **(FREE)**
2019-10-12 21:52:04 +05:30
2020-06-23 00:09:42 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063) in GitLab 12.2.
2020-05-24 23:13:21 +05:30
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/206902) in GitLab 12.10.
2019-10-12 21:52:04 +05:30
2023-03-04 22:38:38 +05:30
A [directed acyclic graph ](https://en.wikipedia.org/wiki/Directed_acyclic_graph ) can be
2019-10-12 21:52:04 +05:30
used in the context of a CI/CD pipeline to build relationships between jobs such that
execution is performed in the quickest possible manner, regardless how stages may
be set up.
For example, you may have a specific tool or separate website that is built
as part of your main project. Using a DAG, you can specify the relationship between
2021-02-22 17:27:13 +05:30
these jobs and GitLab executes the jobs as soon as possible instead of waiting
2019-10-12 21:52:04 +05:30
for each stage to complete.
Unlike other DAG solutions for CI/CD, GitLab does not require you to choose one or the
other. You can implement a hybrid combination of DAG and traditional
stage-based operation within a single pipeline. Configuration is kept very simple,
requiring a single keyword to enable the feature for any job.
Consider a monorepo as follows:
2020-03-13 15:44:24 +05:30
```plaintext
2019-10-12 21:52:04 +05:30
./service_a
./service_b
./service_c
./service_d
```
It has a pipeline that looks like the following:
| build | test | deploy |
| ----- | ---- | ------ |
2023-03-04 22:38:38 +05:30
| `build_a` | `test_a` | `deploy_a` |
| `build_b` | `test_b` | `deploy_b` |
| `build_c` | `test_c` | `deploy_c` |
| `build_d` | `test_d` | `deploy_d` |
2019-10-12 21:52:04 +05:30
Using a DAG, you can relate the `_a` jobs to each other separately from the `_b` jobs,
2021-02-22 17:27:13 +05:30
and even if service `a` takes a very long time to build, service `b` doesn't
wait for it and finishes as quickly as it can. In this very same pipeline, `_c` and
2023-04-23 21:23:45 +05:30
`_d` can be left alone and run together in staged sequence just like any standard
2019-10-12 21:52:04 +05:30
GitLab pipeline.
## Use cases
A DAG can help solve several different kinds of relationships between jobs within
a CI/CD pipeline. Most typically this would cover when jobs need to fan in or out,
and/or merge back together (diamond dependencies). This can happen when you're
handling multi-platform builds or complex webs of dependencies as in something like
an operating system build or a complex deployment graph of independently deployable
but related microservices.
Additionally, a DAG can help with general speediness of pipelines and helping
to deliver fast feedback. By creating dependency relationships that don't unnecessarily
2021-02-22 17:27:13 +05:30
block each other, your pipelines run as quickly as possible regardless of
2019-10-12 21:52:04 +05:30
pipeline stages, ensuring output (including errors) is available to developers
as quickly as possible.
## Usage
2022-01-26 12:08:38 +05:30
Relationships are defined between jobs using the [`needs` keyword ](../yaml/index.md#needs ).
2019-10-12 21:52:04 +05:30
2023-04-23 21:23:45 +05:30
The `needs` keyword also works with the [parallel ](../yaml/index.md#parallel ) keyword,
2019-12-04 20:38:33 +05:30
giving you powerful options for parallelization within your pipeline.
2019-10-12 21:52:04 +05:30
## Limitations
A directed acyclic graph is a complicated feature, and as of the initial MVC there
2021-12-11 22:18:48 +05:30
are certain use cases that you may need to work around. For more information, check the:
2019-10-12 21:52:04 +05:30
2021-12-11 22:18:48 +05:30
- [`needs` additional details ](../yaml/index.md#needs ).
2019-12-21 20:55:43 +05:30
- Related epic [tracking planned improvements ](https://gitlab.com/groups/gitlab-org/-/epics/1716 ).
2020-06-23 00:09:42 +05:30
2021-01-29 00:20:46 +05:30
## Needs Visualization
2020-06-23 00:09:42 +05:30
2023-06-20 00:43:36 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215517) in GitLab 13.1 as a [Beta feature](../../policy/alpha-beta-support.md#beta).
2020-10-24 23:57:45 +05:30
> - It became a [standard feature](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38517) in 13.3.
2021-03-11 19:13:27 +05:30
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52208) in GitLab 13.9.
2020-06-23 00:09:42 +05:30
2021-02-22 17:27:13 +05:30
The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
2020-06-23 00:09:42 +05:30
2022-07-23 23:45:48 +05:30
To see the needs visualization, select **Needs** when viewing a pipeline that uses the `needs` keyword.
2021-01-29 00:20:46 +05:30
2020-06-23 00:09:42 +05:30
2023-01-13 00:05:48 +05:30
Selecting a node highlights all the job paths it depends on.
2020-06-23 00:09:42 +05:30
2021-01-29 00:20:46 +05:30
2021-06-08 01:23:25 +05:30
You can also see `needs` relationships in [full pipeline graphs ](../pipelines/index.md#view-full-pipeline-graph ).
