Merge branch 'main' into DOCSS-1920-find-unlisted-pages

Author: rosieyohannan

docs/guides/modules/ROOT/images/orchestrate-and-trigger/pipeline-definition-id.png

@@ -35,7 +35,7 @@
 
 * Orchestrate
 ** Pipelines
-*** xref:orchestrate:pipelines.adoc[Pipeline and triggers overview]
+*** xref:orchestrate:pipelines.adoc[Pipeline overview and setup]
 *** xref:orchestrate:jobs-steps.adoc[Jobs and steps overview]
 *** xref:orchestrate:workflows.adoc[Workflow orchestration]
 *** xref:orchestrate:automatic-reruns.adoc[Automatic reruns]
@@ -45,7 +45,8 @@
 *** xref:orchestrate:controlling-serial-execution-across-your-organization.adoc[Controlling serial execution across your organization]
 *** xref:orchestrate:pipeline-variables.adoc[Pipeline values and parameters]
 ** Triggers
-*** xref:orchestrate:triggers-overview.adoc[Triggers a pipeline]
+*** xref:orchestrate:triggers-overview.adoc[Trigger options]
+*** xref:orchestrate:set-up-triggers.adoc[Set up triggers]
 *** xref:orchestrate:github-trigger-event-options.adoc[GitHub trigger event options]
 *** xref:orchestrate:gitlab-trigger-options.adoc[GitLab trigger options]
 *** xref:orchestrate:custom-webhooks.adoc[Custom webhooks]

docs/guides/modules/ROOT/images/orchestrate-and-trigger/project-setup-pipelines.png

@@ -48,4 +48,4 @@ Not currently. Scheduled pipelines require highly deterministic inputs such as a
 
 === Why can I not see my pipeline in the scheduled pipeline to run menu?
 
-If you do not see your pipeline in the "Pipeline to run" dropdown menu, it may be that you are trying to access an unsupported pipeline type. Only OAuth pipelines are supported for scheduling, so GitHub App, GitLab, and Bitbucket Data Center pipelines will not appear in the list. You can see the pipeline type by looking at your pipeline list (menu:Project Settings[Pipelines]) and inspecting the pipeline labels.
+If you do not see your pipeline in the "Pipeline to run" dropdown menu, it may be that you are trying to access an unsupported pipeline type. Only OAuth pipelines are supported for scheduling, so GitHub App, GitLab, and Bitbucket Data Center pipelines will not appear in the list. You can see the pipeline type by looking at your pipeline list (menu:Project Settings[Pipelines] or menu:Project Settings[Project Setup]) and inspecting the pipeline labels.

docs/guides/modules/ROOT/images/triggers/add-trigger-github.png

@@ -1,24 +1,16 @@
-. In the link:https://app.circleci.com/[CircleCI web app] select **Projects** in the sidebar.
-. Find your project in the list, select the ellipsis image:guides:ROOT:icons/more.svg[more icon, role="no-border"], select **Project Settings**, and select **Pipelines** in the sidebar.
-. If there is already a GitHub App pipeline set up and it uses the desired YAML configuration file, proceed to the **Triggers** step below (step 5).  If not, select **Set up pipeline**. If there is a **Connect** button, select it and follow the steps to install the CircleCI GitHub App into your GitHub organization (this step is compatible with orgs that integrate with xref:integration:github-integration.adoc#using-github-app-functionality[CircleCI's GitHub OAuth app]).
-. Name the new pipeline and select the repository where the CircleCI YAML configuration file is stored. Enter the file path (including the `.circleci` directory). The file path can be different than `.circleci/config.yml` (for example, `.circleci/webhook.yml`).  Save the pipeline.
-. Select **Triggers** in the sidebar.
-. Select btn:[Add Trigger].
-. Select **Custom Webhook** from the dropdown menu.
-. Select btn:[Next].
+include::ROOT:partial$app-navigation/steps-to-project-settings.adoc[]
+. Select **Project Setup** in the sidebar.
+. If there is already a GitHub App pipeline set up that you want to trigger with your custom webhook, proceed to the **Triggers** step below (step 5).  If not, select btn:[Add Pipeline]. You can find guidance on setting up a pipeline in the xref:orchestrate:pipelines.adoc#add-or-edit-a-pipeline[Pipelines overview and setup] page.
++
+NOTE: If you have not installed the CircleCI GitHub App into your GitHub organization you will be prompted to do so. Installing the GitHub App is a one-time step that can be done by an organization admin. Once installed, further GitHub App pipelines can be set up without this installation step. For a detailed guide to using both OAuth and GitHub App integrations, see the xref:integration:using-the-circleci-github-app-in-an-oauth-org.adoc[Using the CircleCI GitHub App in an OAuth organization] page. If you run into issues when installing the GitHub App, for example, App looks installed on GitHub, but does not show up on CircleCI, submit a request through link:https://forms.gle/aaVERZNNvzsDLJJ46[this form].
+. Select btn:[Custom webhook +] at the bottom of the pipeline box.
+. Enter a descriptive name for the webhook event.
+. Enter the name of the event source for the trigger. For example, if you are setting up a custom webhook to run pipelines on events from Datadog, enter "Datadog" here.
+. Enter the branch to use to fetch your config file and checkout your code when a Custom Webhook is received.
 +
 image::guides:ROOT:triggers/custom-webhooks-add-trigger.png[screenshot showing adding a custom webhook trigger]
-
-. Complete the form fields and options:
-** Enter a descriptive name for the trigger. For example, if you are setting up a custom webhook to run pipelines on events from Datadog, enter "Datadog" here.
-** (Optional) Add a description.
-** In the field "Pipeline to run", at the bottom of the page, select the pipeline that you created in the step above.
-// The field "Pipeline to run" should be above "config branch", because it needs to be selected before entering config branch and checkout branch. This change will be made soon, Benny will update the docs as soon as the change is shipped.
-** Enter the branch to use to fetch your config file when a Custom Webhook is received.
-** Enter the branch to use to check out your code when using the link:https://circleci.com/docs/configuration-reference/#checkout[checkout step] in config. If your config is stored in the same repository as your code, then your **Config branch** and your **Checkout branch** should be the same.
++
 . Select btn:[Save].
 . You will see a webhook endpoint URL and secret. You can use these to set up your webhook trigger from your external source. Copy the Webhook URL and use it in your trigger source appended with the secret.
 +
-CAUTION: The secret will not be shown again so be sure to copy the URL before clicking **Done**.
-+
-image::guides:ROOT:triggers/custom-webhooks-secret-url.png[screenshot showing a custom webhook trigger secret and URL]
+CAUTION: The secret will not be shown again so be sure to copy the URL before clicking **Done**.

docs/guides/modules/ROOT/images/triggers/custom-webhooks-add-trigger.png

@@ -10,8 +10,8 @@ config file .circleci/sample-filename.yml could not be located on branch sample-
 * Ensure that there is a CircleCI configuration file in the repository on the branch that uses the filename specified in the error message. If there is not one present, add a CircleCI configuration file.
 
 * If there is a config file present:
-.. Navigate to menu:Project Settings[Pipelines] in the CircleCI web app for the project where you are seeing this error message.
-.. Select the pencil icon for each pipeline listed and ensure that the "Config File Path" field matches the filepath of the config file that is in your repository. If you changed the name of the config file in your repository, the reference to that filepath must also be changed in the menu:Project Settings[Pipelines] section for any pipeline that uses that configuration file.
+.. Navigate to menu:Project Settings[Pipelines] or menu:Project Settings[Project Setup] in the CircleCI web app for the project where you are seeing this error message.
+.. Ensure that the "Config File Path" field matches the file path of the config file that is in your repository. If you changed the name of the config file in your repository, the reference to that file path must also be changed for any pipeline that uses that configuration file.
 
 [#why-is-my-scheduled-pipeline-not-running]
 === Why is my scheduled pipeline not running?
@@ -44,7 +44,7 @@ In order to keep the system stable for all CircleCI customers, we implement diff
 [#find-project-projects-dashboard]
 === Why can I not find my project on the Projects dashboard?
 
-If you are not seeing a project you would like to build, and it is not currently building on CircleCI, check your org in the top left corner of the CircleCI application. For instance, if the top left shows your user `my-user`, only projects belonging to `my-user` will be available under *Projects*.  If you want to build the project `your-org/project`, you must switch your organization on the application's organization switcher menu to `your-org`.
+If you do not see a project you would like to build, check your org in the top left corner of the CircleCI application. For instance, if the top left shows your user `my-user`, only projects belonging to `my-user` will be available under *Projects*.  If you want to build the project `your-org/project`, you must switch your organization on the application's organization switcher menu to `your-org`.
 
 [#how-do-docker-image-names-work]
 === How do Docker image names work? Where do they come from?
@@ -67,7 +67,7 @@ my-user/couchdb:1.6.1
 [#best-practice-for-specifying-image-versions]
 === What is the best practice for specifying image versions?
 
-It is best practice *not* to use the `latest` tag for specifying image versions. It is also best practice to use a specific version and tag, for example `cimg/ruby:3.0.4-browsers`, to pin down the image and prevent upstream changes to your containers when the underlying base distribution changes. For example, specifying only `cimg/ruby:3.0.4` could result in unexpected changes from `browsers` to `node`. For more context, refer to xref:guides:execution-managed:using-docker.adoc#docker-image-best-practices[Docker image best practices], and xref:guides:execution-managed:circleci-images.adoc#best-practices[CircleCI image best practices].
+It is best practice *not* to use the `latest` tag for specifying image versions. It is also best practice to use a specific version and tag, for example `cimg/ruby:3.0.4-browsers`. Using a specific version and tag pins down the image and prevents upstream changes to your containers when the underlying base distribution changes. For example, specifying only `cimg/ruby:3.0.4` could result in unexpected changes from `browsers` to `node`. For more context, refer to xref:guides:execution-managed:using-docker.adoc#docker-image-best-practices[Docker image best practices], and xref:guides:execution-managed:circleci-images.adoc#best-practices[CircleCI image best practices].
 
 [#set-the-timezone-in-docker-images]
 === How can I set the timezone in Docker images?

docs/guides/modules/ROOT/images/triggers/select-when-to-run.png

@@ -153,12 +153,9 @@ The following settings are available in the project settings page. If you do not
 
 **Groups**: Provides a list of user groups that have been granted project-specific permissions. For more information, see the xref:permissions-authentication:manage-groups.adoc[Manage groups] page.
 
-**Pipelines**: Provides a list of pipelines that have been set up for the project, or the option to begin setting up pipelines if none exist.
+**Project Setup**: Provides a list of GitHub pipelines that have been set up for the project and their associated triggers. See xref:orchestrate:pipelines.adoc[Pipelines Overview and Setup] for more information. Pipelines integrated with VCS different from GitHub are shown in the **Pipelines** tab. This page includes the option to create a first pipeline if none exist. The setup UI for scheduled pipelines is located here for GitHub pipelines or in the *Triggers* section for Bitbucket pipelines. To set up a xref:orchestrate:scheduled-pipelines.adoc[scheduled pipeline] you will define a timetable, parameter, and attribution to automatically run a pipeline when the criteria is met.
 
-**Triggers**: Depending on your integration type, the triggers page shows either:
-
-* A list of configured xref:orchestrate:pipelines.adoc#pipelines-and-triggers[pipeline triggers]
-* Set up UI for scheduled pipelines if available for your integration. To set up a xref:orchestrate:scheduled-pipelines.adoc[scheduled pipeline] you will define a timetable, parameter, and attribution to automatically run a pipeline when the criteria is met.
+*Pipelines* and *Triggers*: These pages let you set up pipelines and triggers when using the GitLab, Bitbucket Cloud and Bitbucket Data Center integrations.
 
 **Deploys**: A UI for managing and viewing deployments. Setup and manage environment integrations, setup components. For full information on the deploys feature, start with the xref:deploy:deployment-overview.adoc[Deployment overview] page.