Add latest changes from gitlab-org/gitlab@master

5 files changed, 72 insertions, 22 deletions

diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 74598ff19a5..4a523ad75ec 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -376,6 +376,7 @@ configuration option in `gitlab.yml`. These metrics are served from the
 | `gitlab_memwd_violations_total`                      | Counter | 15.9    | Total number of times a Sidekiq process violated a memory threshold                                                                                        | |
 | `gitlab_memwd_violations_handled_total`              | Counter | 15.9    | Total number of times Sidekiq process memory violations were handled                                                                                       | |
 | `sidekiq_watchdog_running_jobs_total`                | Counter | 15.9    | Current running jobs when RSS limit was reached                                                                                                            | `worker_class`                                                                                          |
+| `gitlab_maintenance_mode`                            | Gauge   | 15.11   | Is GitLab Maintenance Mode enabled? | |
 
 ## Database load balancing metrics **(PREMIUM SELF)**
 
diff --git a/doc/development/distributed_tracing.md b/doc/development/distributed_tracing.md
index bd9e7035290..fb5f6d03f13 100644
--- a/doc/development/distributed_tracing.md
+++ b/doc/development/distributed_tracing.md
@@ -22,6 +22,14 @@ Distributed tracing adds minimal overhead when disabled, but imposes only small
 enabled and is therefore capable in any environment, including production. For this reason, it can
 be useful in diagnosing production issues, particularly performance problems.
 
+Services have different levels of support for distributed tracing. Custom
+instrumentation code must be added to the application layer in addition to
+pre-built instrumentation for the most common libraries.
+
+For service-specific information, see:
+
+- [Using Jaeger for Gitaly local development](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/jaeger_for_local_development.md)
+
 ## Using Correlation IDs to investigate distributed requests
 
 The GitLab application passes correlation IDs between the various components in a request. A
@@ -80,12 +88,41 @@ In this example, we have the following hypothetical values:
 ## Using Jaeger in the GitLab Development Kit
 
 The first tracing implementation that GitLab supports is Jaeger, and the
-[GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/) supports distributed tracing with
-Jaeger out-of-the-box.
+[GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/)
+supports distributed tracing with Jaeger out-of-the-box. GDK automatically adds
+`GITLAB_TRACING` environment variables to add services.
+
+Configure GDK for Jaeger by editing the `gdk.yml` file and adding the following
+settings:
+
+```yaml
+tracer:
+  build_tags: tracer_static tracer_static_jaeger
+  jaeger:
+    enabled: true
+    listen_address: 127.0.0.1
+    version: 1.43.0
+```
 
-The easiest way to access tracing from a GDK environment is through the
-[performance-bar](../administration/monitoring/performance/performance_bar.md). This can be shown
-by typing `p` `b` in the browser window.
+After modifying the `gdk.yml` file, reconfigure your GDK by running
+the `gdk reconfigure` command. This ensures that your GDK is properly configured
+and ready to use.
+
+The above configuration sets the `tracer_static` and `tracer_static_jaeger`
+build tags when rebuilding services written in Go for the first time. Any
+changes made afterward require rebuilding them with those build tags. You can
+either:
+
+- Add those build tags to the default set of build tags.
+- Manually attach them to the build command. For example, Gitaly supports adding
+  build tag out of the box. You can run
+  `make all WITH_BUNDLED_GIT=YesPlease BUILD_TAGS="tracer_static tracer_static_jaeger"`.
+
+After reconfiguration, Jaeger dashboard is available at
+`http://localhost:16686`. Another way to access tracing from a GDK environment
+is through the
+[performance-bar](../administration/monitoring/performance/performance_bar.md).
+This can be shown by typing `p` `b` in the browser window.
 
 Once the performance bar is enabled, select **Trace** in the performance bar to go to
 the Jaeger UI.
diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md
index 2d9ae768d33..86142efa679 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -70,7 +70,12 @@ don't need to perform this work in parallel.
 This worker imports all pull requests. For every pull request a job for the
 `Gitlab::GithubImport::ImportPullRequestWorker` worker is scheduled.
 
-### 5. Stage::ImportPullRequestsMergedByWorker
+### 5. Stage::ImportCollaboratorsWorker
+
+This worker imports all repository collaborators. For every collaborator, we schedule a job
+for the `Gitlab::GithubImport::ImportCollaboratorWorker` worker.
+
+### 6. Stage::ImportPullRequestsMergedByWorker
 
 This worker imports the pull requests' _merged-by_ user information. The
 [_List pull requests_](https://docs.github.com/en/rest/pulls#list-pull-requests)
@@ -79,21 +84,21 @@ individually to import this information. A
 `Gitlab::GithubImport::ImportPullRequestMergedByWorker` job is scheduled for each fetched pull
 request.
 
-### 6. Stage::ImportPullRequestsReviewRequestsWorker
+### 7. Stage::ImportPullRequestsReviewRequestsWorker
 
 This worker imports assigned reviewers of pull requests. For each pull request, this worker:
 
 - Fetches all assigned review requests.
 - Schedules a `Gitlab::GithubImport::PullRequests::ImportReviewRequestWorker` job for each fetched review request.
 
-### 7. Stage::ImportPullRequestsReviewsWorker
+### 8. Stage::ImportPullRequestsReviewsWorker
 
 This worker imports reviews of pull requests. For each pull request, this worker:
 
 - Fetches all the pages of reviews.
 - Schedules a `Gitlab::GithubImport::ImportPullRequestReviewWorker` job for each fetched review.
 
-### 8. Stage::ImportIssuesAndDiffNotesWorker
+### 9. Stage::ImportIssuesAndDiffNotesWorker
 
 This worker imports all issues and pull request comments. For every issue, we
 schedule a job for the `Gitlab::GithubImport::ImportIssueWorker` worker. For
@@ -109,7 +114,7 @@ label links in the same worker removes the need for performing a separate crawl
 through the API data, reducing the number of API calls necessary to import a
 project.
 
-### 9. Stage::ImportIssueEventsWorker
+### 10. Stage::ImportIssueEventsWorker
 
 This worker imports all issues and pull request events. For every event, we
 schedule a job for the `Gitlab::GithubImport::ImportIssueEventWorker` worker.
@@ -125,7 +130,7 @@ Therefore, both issues and pull requests have a common API for most related thin
 NOTE:
 This stage is optional and can consume significant extra import time (controlled by `Gitlab::GithubImport::Settings`).
 
-### 10. Stage::ImportNotesWorker
+### 11. Stage::ImportNotesWorker
 
 This worker imports regular comments for both issues and pull requests. For
 every comment, we schedule a job for the
@@ -136,7 +141,7 @@ returns comments for both issues and pull requests. This means we have to wait
 for all issues and pull requests to be imported before we can import regular
 comments.
 
-### 11. Stage::ImportAttachmentsWorker
+### 12. Stage::ImportAttachmentsWorker
 
 This worker imports note attachments that are linked inside Markdown.
 For each entity with Markdown text in the project, we schedule a job of:
@@ -155,7 +160,7 @@ Each job:
 NOTE:
 It's an optional stage that could consume significant extra import time (controlled by `Gitlab::GithubImport::Settings`).
 
-### 12. Stage::ImportProtectedBranchesWorker
+### 13. Stage::ImportProtectedBranchesWorker
 
 This worker imports protected branch rules.
 For every rule that exists on GitHub, we schedule a job of
@@ -164,7 +169,7 @@ For every rule that exists on GitHub, we schedule a job of
 Each job compares the branch protection rules from GitHub and GitLab and applies
 the strictest of the rules to the branches in GitLab.
 
-### 13. Stage::FinishImportWorker
+### 14. Stage::FinishImportWorker
 
 This worker completes the import process by performing some housekeeping
 (such as flushing any caches) and by marking the import as completed.
diff --git a/doc/development/prometheus_metrics.md b/doc/development/prometheus_metrics.md
index 590ac547c2d..f72805e0fe9 100644
--- a/doc/development/prometheus_metrics.md
+++ b/doc/development/prometheus_metrics.md
@@ -78,3 +78,15 @@ For example, a histogram with 10 buckets and a label with 100 values would gener
 entries in the export endpoint.
 1. Trigger the relevant page or code that records the new metric.
 1. Check that the new metric appears at `/-/metrics`.
+
+For metrics that are not bounded to a specific context (`request`, `process`, `machine`, `namespace`, etc),
+generate them from a cron-based Sidekiq job:
+
+- For Geo related metrics, check `Geo::MetricsUpdateService`.
+- For other "global" / instance-wide metrics, check: `Metrics::GlobalMetricsUpdateService`.
+
+When exporting data from Sidekiq in an installation with more than one Sidekiq instance,
+you are not guaranteed that the same exporter will always be queried.
+
+You can read more and understand the caveats in [issue 406583](https://gitlab.com/gitlab-org/gitlab/-/issues/406583),
+where we also discuss a possible solution using a push-gateway.
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index 7e99f6e4e8c..acdaef851f5 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -7,7 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Import your project from GitHub to GitLab **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381902) in GitLab 15.8, GitLab no longer automatically creates namespaces or groups that don't exist. GitLab also no longer falls back to using the user's personal namespace if the namespace or group name is taken.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381902) in GitLab 15.8, GitLab no longer automatically creates namespaces or groups that don't exist. GitLab also no longer falls back to using the user's personal namespace if the namespace or group name is taken.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388716) in GitLab 15.10, you no longer need to add any users to the parent group in GitLab to successfully import the **Require a pull request before merging - Allow specified actors to bypass required pull requests** branch protection rule.
 
 You can import your GitHub projects from either GitHub.com or GitHub Enterprise. Importing projects does not
 migrate or import any types of groups or organizations from GitHub to GitLab.
@@ -52,9 +53,6 @@ To import projects from GitHub:
   are properly mapped to the same user in GitLab. GitHub Enterprise does not require this field to be populated so you
   may have to add it on existing accounts.
 
-See also [Branch protection rules and project settings](#branch-protection-rules-and-project-settings) for additional
-prerequisites for those imports.
-
 Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/383047), if you are using GitHub as an OmniAuth provider, ensure that the URL
 perimeter is specified in the [OmniAuth configuration](../../../integration/github.md#enable-github-oauth-in-gitlab).
 
@@ -255,10 +253,7 @@ When they are imported, supported GitHub branch protection rules are mapped to e
 | **Require signed commits** for the project's default branch                                         | **Reject unsigned commits** GitLab [push rule](../repository/push_rules.md#prevent-unintended-consequences) **(PREMIUM)**                                   | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/370949) |
 | **Allow force pushes - Everyone**                                                                   | **Allowed to force push** [branch protection setting](../protected_branches.md#allow-force-push-on-a-protected-branch)                                      | [GitLab 15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/370943) |
 | **Require a pull request before merging - Require review from Code Owners**                         | **Require approval from code owners** [branch protection setting](../protected_branches.md#require-code-owner-approval-on-a-protected-branch) **(PREMIUM)** | [GitLab 15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/376683) |
-| **Require a pull request before merging - Allow specified actors to bypass required pull requests** (1) | List of users in the **Allowed to push** list of [branch protection settings](../protected_branches.md#configure-a-protected-branch) **(PREMIUM)**. Without a Premium license, the list of users that are allowed to push is limited to roles. | [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/384939) |
-
-1. To successfully import the **Require a pull request before merging - Allow specified actors to bypass required pull requests** rule, you must add to the parent group in GitLab
-   the users that are allowed to bypass required pull requests before you begin importing.
+| **Require a pull request before merging - Allow specified actors to bypass required pull requests** | List of users in the **Allowed to push** list of [branch protection settings](../protected_branches.md#configure-a-protected-branch) **(PREMIUM)**. Without a **Premium** subscription, the list of users that are allowed to push is limited to roles. | [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/384939) |
 
 Mapping GitHub rule **Require status checks to pass before merging** to
 [external status checks](../merge_requests/status_checks.md) was considered in issue