diff options
| author | Achilleas Pipinellis <axil@gitlab.com> | 2022-12-05 07:23:42 +0300 |
|---|---|---|
| committer | Marcel Amirault <mamirault@gitlab.com> | 2022-12-05 07:23:42 +0300 |
| commit | 876eb7f95c13f2e5a221010c6575c03b996eaf88 (patch) | |
| tree | 16c8728634841c1106c022aedb01a6b8434f54d4 | |
| parent | c100cb8837f60585d581920d01397faf3e4f901b (diff) | |
Document when to ignore failed pipelines
| -rw-r--r-- | doc/troubleshooting.md | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/troubleshooting.md b/doc/troubleshooting.md index eb32ede6..215a3824 100644 --- a/doc/troubleshooting.md +++ b/doc/troubleshooting.md @@ -36,3 +36,22 @@ with Docker errors are usually intermittent infrastructure problems. These probl resolve themselves with retries. If repeated retries fail, continue troubleshooting. For an example of a job with Docker errors, see: <https://gitlab.com/gitlab-org/gitlab/-/jobs/2834890543>. + +## Failed jobs from upstream review apps + +You can ignore any failures that come from an upstream review app. + +The upstream projects (GitLab, Omnibus GitLab, GitLab Runner, Charts, Operator) +are configured so that you can manually run a docs review app for an open merge request. + +The pipelines for review apps from upstream project MRs run for the `main` branch in the `gitlab-docs` project, +to ensure the review app uses the latest docs site code. +As a result, review app pipeline failures might get posted in the `#docs-site-changes` channel. + +There are a few ways to tell whether a pipeline is from an upstream project: + +- The **build** stage contains the `upstream_test_global_nav_links` job. Note the + `upstream` in the name. +- The **test** stage contains only two jobs: `test_global_nav_links` and + `untamper-my-lockfile`. +- The **deploy** stage contains the `review` job. |