With https://gitlab.com/gitlab-org/gitlab-ce/issues/47063 we plan to introduce support for directed acyclic graphs in GitLab CI pipelines through the use of the `needs:` keyword which will allow you to build a relationship between dependencies that can then be executed as quickly as possible (without regard to stages) by GitLab. Because of the complexity of this feature, we aren't able to address all use cases in the first MVC. This epic is intended to capture the MVC issue as well as the fast-follow items that we plan to deliver to round out the feature better. Infrastructure rollout plan: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7541 ## Other Ideas 1. Reconcile with [existing `dependencies` functionality](https://docs.gitlab.com/ee/ci/yaml/#dependencies) so either we're truly decoupling artifact usage from triggering, or make some reasonable defaults like if you need a job, and that job has artifacts, you probably need the artifacts from it too, so just include them without needing an explicit `dependencies` keyword. Maybe `needs` becomes a successor to `dependencies`. If you need an artifact but also need to wait until a downstream job succeeds (such as testing the artifact), then declaring a `needs` dependency on *both* jobs is a reasonable solution and makes sense, even if not immediately intuitive. And by reconciling both, we solve https://gitlab.com/gitlab-org/gitlab-ce/issues/14728 too. 1. Being able to declare a wildcard pattern for job names so you can quickly depend on similarly named jobs (e.g. `rspec 1 20`, `rspec 2 20`, etc.) 1. If we let you declare a `needs` in another project's pipeline, we could solve multi-project dependencies (https://gitlab.com/gitlab-org/gitlab-ee/issues/1681).