Update the needs keyword to new reference style

doc/administration/cicd.md

@@ -7,22 +7,18 @@ type: howto
 
 # GitLab CI/CD instance configuration **(FREE SELF)**
 
-GitLab CI/CD is enabled by default in all new projects on an instance. You can configure
-the instance to have [GitLab CI/CD disabled by default](#disable-gitlab-cicd-in-new-projects)
-in new projects.
-
-You can still choose to [enable GitLab CI/CD in individual projects](../ci/enable_or_disable_ci.md#enable-cicd-in-a-project)
-at any time.
+GitLab administrators can manage the GitLab CI/CD configuration for their instance.
 
 ## Disable GitLab CI/CD in new projects
 
-You can set GitLab CI/CD to be disabled by default in all new projects by modifying the settings in:
+GitLab CI/CD is enabled by default in all new projects on an instance. You can set
+CI/CD to be disabled by default in new projects by modifying the settings in:
 
 - `gitlab.yml` for source installations.
 - `gitlab.rb` for Omnibus GitLab installations.
 
 Existing projects that already had CI/CD enabled are unchanged. Also, this setting only changes
-the project default, so project owners can still enable CI/CD in the project settings.
+the project default, so project owners [can still enable CI/CD in the project settings](../ci/enable_or_disable_ci.md#enable-cicd-in-a-project).
 
 For installations from source:
 
@@ -62,6 +58,19 @@ For Omnibus GitLab installations:
    sudo gitlab-ctl reconfigure
    ```
 
+## Set the `needs:` job limit **(FREE SELF)**
+
+The maximum number of jobs that can be defined in `needs:` defaults to 50.
+
+A GitLab administrator with [access to the GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session)
+can choose a custom limit. For example, to set the limit to `100`:
+
+```ruby
+Plan.default.actual_limits.update!(ci_needs_size_limit: 100)
+```
+
+To disable directed acyclic graphs (DAG), set the limit to `0`.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues

doc/ci/directed_acyclic_graph/index.md

@@ -74,9 +74,9 @@ giving you powerful options for parallelization within your pipeline.
 ## Limitations
 
 A directed acyclic graph is a complicated feature, and as of the initial MVC there
-are certain use cases that you may need to work around. For more information:
+are certain use cases that you may need to work around. For more information, check the:
 
-- [`needs` requirements and limitations](../yaml/index.md#requirements-and-limitations).
+- [`needs` additional details](../yaml/index.md#needs).
 - Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716).
 
 ## Needs Visualization

doc/ci/pipelines/multi_project_pipelines.md

@@ -88,7 +88,7 @@ The keywords available for use in trigger jobs are:
 - [`only` and `except`](../yaml/index.md#only--except)
 - [`when`](../yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
 - [`extends`](../yaml/index.md#extends)
-- [`needs`](../yaml/index.md#needs), but not [cross project artifact downloads with `needs`](../yaml/index.md#cross-project-artifact-downloads-with-needs)
+- [`needs`](../yaml/index.md#needs), but not [`needs:project`](../yaml/index.md#needsproject)
 
 #### Specify a downstream pipeline branch
 
@@ -190,7 +190,7 @@ 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](../variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](../yaml/index.md#cross-project-artifact-downloads-with-needs).
+You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job) and [`needs:project`](../yaml/index.md#needsproject).
 
 In the upstream pipeline:
 
@@ -254,21 +254,6 @@ trigger_job:
     strategy: depend
 ```
 
-#### 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.
-
-For example:
-
-```yaml
-upstream_bridge:
-  stage: test
-  needs:
-    pipeline: other/project
-```
-
 ### Create multi-project pipelines by using the API
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.

doc/ci/variables/index.md

@@ -557,7 +557,7 @@ they can be used in job scripts.
 1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/index.md#artifactsreportsdotenv)
 artifact.
 1. Set a job in a later stage to receive the artifact by using the [`dependencies`](../yaml/index.md#dependencies)
-   or the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keywords.
+   or the [`needs`](../yaml/index.md#needs) keywords.
 1. The later job can then [use the variable in scripts](#use-cicd-variables-in-job-scripts).
 
 For example, with the [`dependencies`](../yaml/index.md#dependencies) keyword:
@@ -579,7 +579,7 @@ deploy:
     - build
 ```
 
-For example, with the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keyword:
+For example, with the [`needs:artifacts`](../yaml/index.md#needsartifacts) keyword:
 
 ```yaml
 build: