Add latest changes from gitlab-org/gitlab@master

4 files changed, 14 insertions, 29 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 426a235823f..3ce794514a3 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -294,13 +294,13 @@ or by calling `#to_global_id` on an object that has mixed in the
 `GlobalID::Identification` module.
 
 Using an example from
-[`Types::Notes::DiscussionType`](https://gitlab.com/gitlab-org/gitlab/-/blob/3c95bd9/app/graphql/types/notes/discussion_type.rb#L24-26):
+[`Types::Notes::DiscussionType`](https://gitlab.com/gitlab-org/gitlab/-/blob/af48df44/app/graphql/types/notes/discussion_type.rb#L22-30):
 
 ```ruby
-field :reply_id, GraphQL::Types::ID
+field :reply_id, Types::GlobalIDType[Discussion]
 
 def reply_id
-  ::Gitlab::GlobalId.build(object, id: object.reply_id)
+  Gitlab::GlobalId.build(object, id: object.reply_id)
 end
 ```
 
diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md
index 6f42cb4d4fe..0b45e83bb26 100644
--- a/doc/development/integrations/index.md
+++ b/doc/development/integrations/index.md
@@ -23,9 +23,11 @@ if you need clarification or spot any outdated information.
    - For example, `Integrations::FooBar` in `app/models/integrations/foo_bar.rb`.
    - For certain types of integrations, you can also build on these base classes:
      - `Integrations::BaseChatNotification`
+     - `Integrations::BaseCi`
      - `Integrations::BaseIssueTracker`
      - `Integrations::BaseMonitoring`
      - `Integrations::BaseSlashCommands`
+     - `Integrations::BaseThirdPartyWiki`
    - For integrations that primarily trigger HTTP calls to external services, you can
      also use the `Integrations::HasWebHook` concern. This reuses the [webhook functionality](../../user/project/integrations/webhooks.md)
      in GitLab through an associated `ServiceHook` model, and automatically records request logs
@@ -37,9 +39,6 @@ if you need clarification or spot any outdated information.
    has_one :foo_bar_integration, class_name: 'Integrations::FooBar'
    ```
 
-1. TEMPORARY: Accommodate the current migration to [rename "services" to "integrations"](#rename-services-to-integrations):
-   - Add the integration's camel-cased name (`'FooBar'`) to `Gitlab::Integrations::StiType::NAMESPACED_INTEGRATIONS`.
-
 ### Define properties
 
 Integrations can define arbitrary properties to store their configuration with the class method `Integration.prop_accessor`.
@@ -345,26 +344,8 @@ The strings should use the integration name as [namespace](../i18n/externalizati
 
 ## Ongoing migrations and refactorings
 
-The Integrations team is in the process of some larger migrations that developers should be aware of.
-
-### [Rename "services" to "integrations"](https://gitlab.com/groups/gitlab-org/-/epics/2504)
-
-The "integrations" in GitLab were historically called "services", which frequently caused
-confusion with our "service" classes in `app/services`. We sometimes also called
-them "project services" because they were initially only available on projects, which is
-not the case anymore.
-
-We decided to change the naming from "services" and "project services" to "integrations".
-This refactoring is an ongoing effort, and there are still references to the old names in some places.
-
-Developers should be especially aware that we still use the old class names for the STI column
-`integrations.type`. For example, a class `Integrations::FooBar` still stores
-the old name `FooBarService` in the database. This mapping is handled via `Gitlab::Integrations::StiType`
-and should be mostly transparent to the rest of the app.
-
-### [Consolidate integration settings](https://gitlab.com/groups/gitlab-org/-/epics/3955)
-
-We want to unify the way integration properties are defined.
+Developers should be aware that the Integrations team is in the process of
+[unifying the way integration properties are defined](https://gitlab.com/groups/gitlab-org/-/epics/3955).
 
 ## Integration examples
 
diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md
index a76432e9af6..1bcbb42fc8e 100644
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@@ -172,6 +172,10 @@ helm upgrade --install gitlab-agent gitlab/gitlab-agent \
   ...
 ```
 
+NOTE:
+DNS rebind protection is disabled when either the `HTTP_PROXY` or the `HTTPS_PROXY` environment variable is set,
+and the domain DNS can't be resolved.
+
 #### Advanced installation method
 
 GitLab also provides a [KPT package for the agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/build/deployment/gitlab-agent). This method provides greater flexibility, but is only recommended for advanced users.
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index acdaef851f5..657343261d9 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -9,6 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [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.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/378267) in GitLab 15.11, GitLab instances behind proxies no longer require `github.com` and `api.github.com` entries in the [allowlist for local requests](../../../security/webhooks.md#allow-outbound-requests-to-certain-ip-addresses-and-domains).
 
 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.
@@ -61,9 +62,8 @@ perimeter is specified in the [OmniAuth configuration](../../../integration/gith
 If you are importing from GitHub Enterprise to a self-managed GitLab instance:
 
 - You must first enable the [GitHub integration](../../../integration/github.md).
-- If GitLab is behind an HTTP/HTTPS proxy, you must populate the [allowlist for local requests](../../../security/webhooks.md#allow-outbound-requests-to-certain-ip-addresses-and-domains)
-  with `github.com` and `api.github.com` to solve the hostname. For more information, read the issue
-  [Importing a GitHub project requires DNS resolution even when behind a proxy](https://gitlab.com/gitlab-org/gitlab/-/issues/37941).
+- For GitLab 15.10 and earlier, you must add `github.com` and `api.github.com` entries in the
+  [allowlist for local requests](../../../security/webhooks.md#allow-outbound-requests-to-certain-ip-addresses-and-domains).
 
 ### Importing from GitHub.com to self-managed GitLab