Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2020-11-10 03:08:52 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2020-11-10 03:08:52 +0300
commit1b1d9cdc17e24711e9074e24c0a4e83446153f7d (patch)
tree4f185c8c2d976cb95e2ddd29ed55ae9fb69df0c4
parentf29dae9f106150cd85d4fb107f1eb3b0281e6968 (diff)
Add latest changes from gitlab-org/gitlab@master
-rw-r--r--.rubocop_manual_todo.yml3
-rw-r--r--app/assets/javascripts/pipelines/components/header_component.vue58
-rw-r--r--app/assets/javascripts/pipelines/graphql/mutations/cancel_pipeline.mutation.graphql5
-rw-r--r--app/assets/javascripts/pipelines/graphql/mutations/delete_pipeline.mutation.graphql5
-rw-r--r--app/assets/javascripts/pipelines/graphql/mutations/retry_pipeline.mutation.graphql5
-rw-r--r--app/assets/javascripts/pipelines/pipeline_details_header.js6
-rw-r--r--app/graphql/resolvers/alert_management/integrations_resolver.rb2
-rw-r--r--app/graphql/resolvers/base_resolver.rb86
-rw-r--r--app/graphql/resolvers/design_management/design_at_version_resolver.rb2
-rw-r--r--app/graphql/resolvers/design_management/design_resolver.rb2
-rw-r--r--app/graphql/resolvers/design_management/designs_resolver.rb2
-rw-r--r--app/graphql/resolvers/error_tracking/sentry_detailed_error_resolver.rb2
-rw-r--r--app/graphql/resolvers/error_tracking/sentry_error_collection_resolver.rb2
-rw-r--r--app/graphql/resolvers/error_tracking/sentry_errors_resolver.rb2
-rw-r--r--app/graphql/resolvers/group_members_resolver.rb2
-rw-r--r--app/graphql/resolvers/issues_resolver.rb2
-rw-r--r--app/graphql/resolvers/project_pipeline_resolver.rb2
-rw-r--r--app/graphql/resolvers/projects/jira_imports_resolver.rb2
-rw-r--r--app/graphql/resolvers/projects/jira_projects_resolver.rb2
-rw-r--r--app/graphql/resolvers/projects/services_resolver.rb2
-rw-r--r--app/graphql/resolvers/snippets/blobs_resolver.rb2
-rw-r--r--app/graphql/resolvers/todo_resolver.rb2
-rw-r--r--app/graphql/resolvers/tree_resolver.rb2
-rw-r--r--app/graphql/resolvers/users_resolver.rb1
-rw-r--r--app/models/design_management/version.rb5
-rw-r--r--app/views/projects/pipelines/show.html.haml2
-rw-r--r--app/views/shared/wikis/_sidebar.html.haml2
-rw-r--r--config/sidekiq_queues.yml2
-rw-r--r--doc/.vale/gitlab/Substitutions.yml8
-rw-r--r--doc/administration/auth/crowd.md4
-rw-r--r--doc/administration/auth/ldap/index.md9
-rw-r--r--doc/administration/auth/ldap/ldap-troubleshooting.md27
-rw-r--r--doc/administration/geo/disaster_recovery/index.md10
-rw-r--r--doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md5
-rw-r--r--doc/administration/geo/index.md5
-rw-r--r--doc/administration/geo/replication/configuration.md12
-rw-r--r--doc/administration/geo/replication/datatypes.md2
-rw-r--r--doc/administration/geo/replication/location_aware_git_url.md4
-rw-r--r--doc/administration/geo/replication/object_storage.md2
-rw-r--r--doc/administration/geo/replication/troubleshooting.md3
-rw-r--r--doc/administration/geo/replication/updating_the_geo_nodes.md6
-rw-r--r--doc/administration/geo/replication/version_specific_updates.md132
-rw-r--r--doc/administration/nfs.md10
-rw-r--r--doc/administration/operations/fast_ssh_key_lookup.md5
-rw-r--r--doc/administration/packages/container_registry.md8
-rw-r--r--doc/administration/packages/index.md64
-rw-r--r--doc/administration/postgresql/replication_and_failover.md11
-rw-r--r--doc/administration/reply_by_email.md2
-rw-r--r--doc/ci/docker/using_docker_images.md22
-rw-r--r--doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md26
-rw-r--r--doc/development/documentation/index.md21
-rw-r--r--doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md6
-rw-r--r--doc/install/azure/index.md16
-rw-r--r--doc/install/openshift_and_gitlab/index.md26
-rw-r--r--doc/integration/github.md14
-rw-r--r--doc/integration/kerberos.md25
-rw-r--r--doc/integration/omniauth.md51
-rw-r--r--doc/integration/saml.md32
-rw-r--r--doc/integration/vault.md12
-rw-r--r--doc/security/reset_user_password.md7
-rw-r--r--doc/security/two_factor_authentication.md22
-rw-r--r--doc/system_hooks/system_hooks.md17
-rw-r--r--doc/user/admin_area/settings/index.md2
-rw-r--r--doc/user/application_security/container_scanning/index.md22
-rw-r--r--doc/user/packages/nuget_repository/index.md2
-rw-r--r--doc/user/profile/account/two_factor_authentication.md19
-rw-r--r--doc/user/project/deploy_tokens/index.md69
-rw-r--r--spec/factories/design_management/design_at_version.rb6
-rw-r--r--spec/factories/design_management/designs.rb4
-rw-r--r--spec/factories/design_management/versions.rb4
-rw-r--r--spec/frontend/pipelines/header_component_spec.js55
-rw-r--r--spec/graphql/resolvers/alert_management/integrations_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/base_resolver_spec.rb184
-rw-r--r--spec/graphql/resolvers/design_management/design_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/design_management/designs_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/echo_resolver_spec.rb5
-rw-r--r--spec/graphql/resolvers/error_tracking/sentry_detailed_error_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/error_tracking/sentry_error_collection_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/error_tracking/sentry_errors_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/group_members_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/issues_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/project_pipeline_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/projects/jira_imports_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/projects/jira_projects_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/projects/services_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/snippets/blobs_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/todo_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/tree_resolver_spec.rb4
-rw-r--r--spec/graphql/resolvers/users_resolver_spec.rb4
-rw-r--r--spec/models/design_management/design_at_version_spec.rb2
-rw-r--r--spec/models/design_management/version_spec.rb2
-rw-r--r--spec/support/matchers/graphql_matchers.rb77
92 files changed, 922 insertions, 433 deletions
diff --git a/.rubocop_manual_todo.yml b/.rubocop_manual_todo.yml
index a236073c089..cf8d25d2476 100644
--- a/.rubocop_manual_todo.yml
+++ b/.rubocop_manual_todo.yml
@@ -6,9 +6,6 @@ FactoryBot/InlineAssociation:
- 'ee/spec/factories/merge_request_blocks.rb'
- 'ee/spec/factories/vulnerabilities/feedback.rb'
- 'spec/factories/atlassian_identities.rb'
- - 'spec/factories/design_management/design_at_version.rb'
- - 'spec/factories/design_management/designs.rb'
- - 'spec/factories/design_management/versions.rb'
- 'spec/factories/events.rb'
- 'spec/factories/git_wiki_commit_details.rb'
- 'spec/factories/gitaly/commit.rb'
diff --git a/app/assets/javascripts/pipelines/components/header_component.vue b/app/assets/javascripts/pipelines/components/header_component.vue
index b26f28fa6af..690ea962336 100644
--- a/app/assets/javascripts/pipelines/components/header_component.vue
+++ b/app/assets/javascripts/pipelines/components/header_component.vue
@@ -1,16 +1,21 @@
<script>
import { GlAlert, GlButton, GlLoadingIcon, GlModal, GlModalDirective } from '@gitlab/ui';
import { __ } from '~/locale';
-import axios from '~/lib/utils/axios_utils';
import ciHeader from '~/vue_shared/components/header_ci_component.vue';
import { setUrlFragment, redirectTo } from '~/lib/utils/url_utility';
import getPipelineQuery from '../graphql/queries/get_pipeline_header_data.query.graphql';
+import deletePipelineMutation from '../graphql/mutations/delete_pipeline.mutation.graphql';
+import retryPipelineMutation from '../graphql/mutations/retry_pipeline.mutation.graphql';
+import cancelPipelineMutation from '../graphql/mutations/cancel_pipeline.mutation.graphql';
import { LOAD_FAILURE, POST_FAILURE, DELETE_FAILURE, DEFAULT } from '../constants';
const DELETE_MODAL_ID = 'pipeline-delete-modal';
+const POLL_INTERVAL = 10000;
export default {
name: 'PipelineHeaderSection',
+ pipelineCancel: 'pipelineCancel',
+ pipelineRetry: 'pipelineRetry',
components: {
ciHeader,
GlAlert,
@@ -28,7 +33,7 @@ export default {
[DEFAULT]: __('An unknown error occurred.'),
},
inject: {
- // Receive `cancel`, `delete`, `fullProject` and `retry`
+ // Receive `fullProject` and `pipelinesPath`
paths: {
default: {},
},
@@ -52,7 +57,7 @@ export default {
error() {
this.reportFailure(LOAD_FAILURE);
},
- pollInterval: 10000,
+ pollInterval: POLL_INTERVAL,
watchLoading(isLoading) {
if (!isLoading) {
// To ensure apollo has updated the cache,
@@ -122,31 +127,58 @@ export default {
reportFailure(errorType) {
this.failureType = errorType;
},
- async postAction(path) {
+ async postPipelineAction(name, mutation) {
try {
- await axios.post(path);
- this.$apollo.queries.pipeline.refetch();
+ const {
+ data: {
+ [name]: { errors },
+ },
+ } = await this.$apollo.mutate({
+ mutation,
+ variables: { id: this.pipeline.id },
+ });
+
+ if (errors.length > 0) {
+ this.reportFailure(POST_FAILURE);
+ } else {
+ this.$apollo.queries.pipeline.refetch();
+ }
} catch {
this.reportFailure(POST_FAILURE);
}
},
- async cancelPipeline() {
+ cancelPipeline() {
this.isCanceling = true;
- this.postAction(this.paths.cancel);
+ this.postPipelineAction(this.$options.pipelineCancel, cancelPipelineMutation);
},
- async retryPipeline() {
+ retryPipeline() {
this.isRetrying = true;
- this.postAction(this.paths.retry);
+ this.postPipelineAction(this.$options.pipelineRetry, retryPipelineMutation);
},
async deletePipeline() {
this.isDeleting = true;
this.$apollo.queries.pipeline.stopPolling();
try {
- const { request } = await axios.delete(this.paths.delete);
- redirectTo(setUrlFragment(request.responseURL, 'delete_success'));
+ const {
+ data: {
+ pipelineDestroy: { errors },
+ },
+ } = await this.$apollo.mutate({
+ mutation: deletePipelineMutation,
+ variables: {
+ id: this.pipeline.id,
+ },
+ });
+
+ if (errors.length > 0) {
+ this.reportFailure(DELETE_FAILURE);
+ this.isDeleting = false;
+ } else {
+ redirectTo(setUrlFragment(this.paths.pipelinesPath, 'delete_success'));
+ }
} catch {
- this.$apollo.queries.pipeline.startPolling();
+ this.$apollo.queries.pipeline.startPolling(POLL_INTERVAL);
this.reportFailure(DELETE_FAILURE);
this.isDeleting = false;
}
diff --git a/app/assets/javascripts/pipelines/graphql/mutations/cancel_pipeline.mutation.graphql b/app/assets/javascripts/pipelines/graphql/mutations/cancel_pipeline.mutation.graphql
new file mode 100644
index 00000000000..9afb474cb17
--- /dev/null
+++ b/app/assets/javascripts/pipelines/graphql/mutations/cancel_pipeline.mutation.graphql
@@ -0,0 +1,5 @@
+mutation cancelPipeline($id: CiPipelineID!) {
+ pipelineCancel(input: { id: $id }) {
+ errors
+ }
+}
diff --git a/app/assets/javascripts/pipelines/graphql/mutations/delete_pipeline.mutation.graphql b/app/assets/javascripts/pipelines/graphql/mutations/delete_pipeline.mutation.graphql
new file mode 100644
index 00000000000..a52cecafcaf
--- /dev/null
+++ b/app/assets/javascripts/pipelines/graphql/mutations/delete_pipeline.mutation.graphql
@@ -0,0 +1,5 @@
+mutation deletePipeline($id: CiPipelineID!) {
+ pipelineDestroy(input: { id: $id }) {
+ errors
+ }
+}
diff --git a/app/assets/javascripts/pipelines/graphql/mutations/retry_pipeline.mutation.graphql b/app/assets/javascripts/pipelines/graphql/mutations/retry_pipeline.mutation.graphql
new file mode 100644
index 00000000000..2b3b0822653
--- /dev/null
+++ b/app/assets/javascripts/pipelines/graphql/mutations/retry_pipeline.mutation.graphql
@@ -0,0 +1,5 @@
+mutation retryPipeline($id: CiPipelineID!) {
+ pipelineRetry(input: { id: $id }) {
+ errors
+ }
+}
diff --git a/app/assets/javascripts/pipelines/pipeline_details_header.js b/app/assets/javascripts/pipelines/pipeline_details_header.js
index 27fe9ba3f19..744a8272709 100644
--- a/app/assets/javascripts/pipelines/pipeline_details_header.js
+++ b/app/assets/javascripts/pipelines/pipeline_details_header.js
@@ -16,7 +16,7 @@ export const createPipelineHeaderApp = elSelector => {
return;
}
- const { cancelPath, deletePath, fullPath, pipelineId, pipelineIid, retryPath } = el?.dataset;
+ const { fullPath, pipelineId, pipelineIid, pipelinesPath } = el?.dataset;
// eslint-disable-next-line no-new
new Vue({
el,
@@ -26,10 +26,8 @@ export const createPipelineHeaderApp = elSelector => {
apolloProvider,
provide: {
paths: {
- cancel: cancelPath,
- delete: deletePath,
fullProject: fullPath,
- retry: retryPath,
+ pipelinesPath,
},
pipelineId,
pipelineIid,
diff --git a/app/graphql/resolvers/alert_management/integrations_resolver.rb b/app/graphql/resolvers/alert_management/integrations_resolver.rb
index b50da1cfde5..ff31d933bf2 100644
--- a/app/graphql/resolvers/alert_management/integrations_resolver.rb
+++ b/app/graphql/resolvers/alert_management/integrations_resolver.rb
@@ -5,6 +5,8 @@ module Resolvers
class IntegrationsResolver < BaseResolver
alias_method :project, :synchronized_object
+ type Types::AlertManagement::IntegrationType.connection_type, null: true
+
def resolve(**args)
return [] unless Feature.enabled?(:multiple_http_integrations, project)
diff --git a/app/graphql/resolvers/base_resolver.rb b/app/graphql/resolvers/base_resolver.rb
index 2b8854fb4d0..87a63231b22 100644
--- a/app/graphql/resolvers/base_resolver.rb
+++ b/app/graphql/resolvers/base_resolver.rb
@@ -8,32 +8,81 @@ module Resolvers
argument_class ::Types::BaseArgument
- def self.single
- @single ||= Class.new(self) do
- def ready?(**args)
- ready, early_return = super
- [ready, select_result(early_return)]
- end
+ def self.singular_type
+ return unless type
- def resolve(**args)
- select_result(super)
- end
+ unwrapped = type.unwrap
+
+ %i[node_type relay_node_type of_type itself].reduce(nil) do |t, m|
+ t || unwrapped.try(m)
+ end
+ end
- def single?
- true
+ def self.when_single(&block)
+ as_single << block
+
+ # Have we been called after defining the single version of this resolver?
+ if @single.present?
+ @single.instance_exec(&block)
+ end
+ end
+
+ def self.as_single
+ @as_single ||= []
+ end
+
+ def self.single_definition_blocks
+ ancestors.flat_map { |klass| klass.try(:as_single) || [] }
+ end
+
+ def self.single
+ @single ||= begin
+ parent = self
+ klass = Class.new(self) do
+ type parent.singular_type, null: true
+
+ def ready?(**args)
+ ready, early_return = super
+ [ready, select_result(early_return)]
+ end
+
+ def resolve(**args)
+ select_result(super)
+ end
+
+ def single?
+ true
+ end
+
+ def select_result(results)
+ results&.first
+ end
+
+ define_singleton_method :to_s do
+ "#{parent}.single"
+ end
end
- def select_result(results)
- results&.first
+ single_definition_blocks.each do |definition|
+ klass.instance_exec(&definition)
end
+
+ klass
end
end
def self.last
+ parent = self
@last ||= Class.new(self.single) do
+ type parent.singular_type, null: true
+
def select_result(results)
results&.last
end
+
+ define_singleton_method :to_s do
+ "#{parent}.last"
+ end
end
end
@@ -68,14 +117,13 @@ module Resolvers
end
end
+ # TODO: remove! This should never be necessary
+ # Remove as part of https://gitlab.com/gitlab-org/gitlab/-/issues/13984,
+ # since once we use that authorization approach, the object is guaranteed to
+ # be synchronized before any field.
def synchronized_object
strong_memoize(:synchronized_object) do
- case object
- when BatchLoader::GraphQL
- object.sync
- else
- object
- end
+ ::Gitlab::Graphql::Lazy.force(object)
end
end
diff --git a/app/graphql/resolvers/design_management/design_at_version_resolver.rb b/app/graphql/resolvers/design_management/design_at_version_resolver.rb
index b0da43abd54..1b69efebe4e 100644
--- a/app/graphql/resolvers/design_management/design_at_version_resolver.rb
+++ b/app/graphql/resolvers/design_management/design_at_version_resolver.rb
@@ -38,7 +38,7 @@ module Resolvers
# that the DesignAtVersion as found by its ID does in fact belong
# to this issue.
def consistent?(dav)
- issue.nil? || (dav&.design&.issue_id == issue.id)
+ issue.nil? || (dav.present? && dav.design&.issue_id == issue.id)
end
def issue
diff --git a/app/graphql/resolvers/design_management/design_resolver.rb b/app/graphql/resolvers/design_management/design_resolver.rb
index 43b5242c2b0..e0a68bae397 100644
--- a/app/graphql/resolvers/design_management/design_resolver.rb
+++ b/app/graphql/resolvers/design_management/design_resolver.rb
@@ -3,6 +3,8 @@
module Resolvers
module DesignManagement
class DesignResolver < BaseResolver
+ type ::Types::DesignManagement::DesignType, null: true
+
argument :id, ::Types::GlobalIDType[::DesignManagement::Design],
required: false,
description: 'Find a design by its ID'
diff --git a/app/graphql/resolvers/design_management/designs_resolver.rb b/app/graphql/resolvers/design_management/designs_resolver.rb
index 5327feba7f0..c588142ea6b 100644
--- a/app/graphql/resolvers/design_management/designs_resolver.rb
+++ b/app/graphql/resolvers/design_management/designs_resolver.rb
@@ -6,6 +6,8 @@ module Resolvers
DesignID = ::Types::GlobalIDType[::DesignManagement::Design]
VersionID = ::Types::GlobalIDType[::DesignManagement::Version]
+ type ::Types::DesignManagement::DesignType.connection_type, null: true
+
argument :ids, [DesignID],
required: false,
description: 'Filters designs by their ID'
diff --git a/app/graphql/resolvers/error_tracking/sentry_detailed_error_resolver.rb b/app/graphql/resolvers/error_tracking/sentry_detailed_error_resolver.rb
index 5027403e95c..07e70d5c819 100644
--- a/app/graphql/resolvers/error_tracking/sentry_detailed_error_resolver.rb
+++ b/app/graphql/resolvers/error_tracking/sentry_detailed_error_resolver.rb
@@ -3,6 +3,8 @@
module Resolvers
module ErrorTracking
class SentryDetailedErrorResolver < BaseResolver
+ type Types::ErrorTracking::SentryDetailedErrorType, null: true
+
argument :id, GraphQL::ID_TYPE,
required: true,
description: 'ID of the Sentry issue'
diff --git a/app/graphql/resolvers/error_tracking/sentry_error_collection_resolver.rb b/app/graphql/resolvers/error_tracking/sentry_error_collection_resolver.rb
index e4b4854c273..d47cc2bae56 100644
--- a/app/graphql/resolvers/error_tracking/sentry_error_collection_resolver.rb
+++ b/app/graphql/resolvers/error_tracking/sentry_error_collection_resolver.rb
@@ -3,6 +3,8 @@
module Resolvers
module ErrorTracking
class SentryErrorCollectionResolver < BaseResolver
+ type Types::ErrorTracking::SentryErrorCollectionType, null: true
+
def resolve(**args)
project = object
diff --git a/app/graphql/resolvers/error_tracking/sentry_errors_resolver.rb b/app/graphql/resolvers/error_tracking/sentry_errors_resolver.rb
index 79f99709505..c5cf924ce7f 100644
--- a/app/graphql/resolvers/error_tracking/sentry_errors_resolver.rb
+++ b/app/graphql/resolvers/error_tracking/sentry_errors_resolver.rb
@@ -3,6 +3,8 @@
module Resolvers
module ErrorTracking
class SentryErrorsResolver < BaseResolver
+ type Types::ErrorTracking::SentryErrorType.connection_type, null: true
+
def resolve(**args)
args[:cursor] = args.delete(:after)
project = object.project
diff --git a/app/graphql/resolvers/group_members_resolver.rb b/app/graphql/resolvers/group_members_resolver.rb
index f34c873a8a9..d3aa376c29c 100644
--- a/app/graphql/resolvers/group_members_resolver.rb
+++ b/app/graphql/resolvers/group_members_resolver.rb
@@ -2,6 +2,8 @@
module Resolvers
class GroupMembersResolver < MembersResolver
+ type Types::GroupMemberType.connection_type, null: true
+
authorize :read_group_member
private
diff --git a/app/graphql/resolvers/issues_resolver.rb b/app/graphql/resolvers/issues_resolver.rb
index 396ae02ae13..dd35219454f 100644
--- a/app/graphql/resolvers/issues_resolver.rb
+++ b/app/graphql/resolvers/issues_resolver.rb
@@ -12,7 +12,7 @@ module Resolvers
required: false,
default_value: 'created_desc'
- type Types::IssueType, null: true
+ type Types::IssueType.connection_type, null: true
NON_STABLE_CURSOR_SORTS = %i[priority_asc priority_desc
label_priority_asc label_priority_desc
diff --git a/app/graphql/resolvers/project_pipeline_resolver.rb b/app/graphql/resolvers/project_pipeline_resolver.rb
index 181c1e77109..4cf47dbdc60 100644
--- a/app/graphql/resolvers/project_pipeline_resolver.rb
+++ b/app/graphql/resolvers/project_pipeline_resolver.rb
@@ -2,6 +2,8 @@
module Resolvers
class ProjectPipelineResolver < BaseResolver
+ type ::Types::Ci::PipelineType, null: true
+
alias_method :project, :object
argument :iid, GraphQL::ID_TYPE,
diff --git a/app/graphql/resolvers/projects/jira_imports_resolver.rb b/app/graphql/resolvers/projects/jira_imports_resolver.rb
index aa9b7139f38..efd45c2c465 100644
--- a/app/graphql/resolvers/projects/jira_imports_resolver.rb
+++ b/app/graphql/resolvers/projects/jira_imports_resolver.rb
@@ -3,6 +3,8 @@
module Resolvers
module Projects
class JiraImportsResolver < BaseResolver
+ type Types::JiraImportType.connection_type, null: true
+
include Gitlab::Graphql::Authorize::AuthorizeResource
alias_method :project, :object
diff --git a/app/graphql/resolvers/projects/jira_projects_resolver.rb b/app/graphql/resolvers/projects/jira_projects_resolver.rb
index d017f973e17..31f42d305b0 100644
--- a/app/graphql/resolvers/projects/jira_projects_resolver.rb
+++ b/app/graphql/resolvers/projects/jira_projects_resolver.rb
@@ -5,6 +5,8 @@ module Resolvers
class JiraProjectsResolver < BaseResolver
include Gitlab::Graphql::Authorize::AuthorizeResource
+ type Types::Projects::Services::JiraProjectType.connection_type, null: true
+
argument :name,
GraphQL::STRING_TYPE,
required: false,
diff --git a/app/graphql/resolvers/projects/services_resolver.rb b/app/graphql/resolvers/projects/services_resolver.rb
index 40c64c24513..17d81e21c28 100644
--- a/app/graphql/resolvers/projects/services_resolver.rb
+++ b/app/graphql/resolvers/projects/services_resolver.rb
@@ -5,6 +5,8 @@ module Resolvers
class ServicesResolver < BaseResolver
include Gitlab::Graphql::Authorize::AuthorizeResource
+ type Types::Projects::ServiceType.connection_type, null: true
+
argument :active,
GraphQL::BOOLEAN_TYPE,
required: false,
diff --git a/app/graphql/resolvers/snippets/blobs_resolver.rb b/app/graphql/resolvers/snippets/blobs_resolver.rb
index dc28358cab6..3a0dcb50faf 100644
--- a/app/graphql/resolvers/snippets/blobs_resolver.rb
+++ b/app/graphql/resolvers/snippets/blobs_resolver.rb
@@ -5,6 +5,8 @@ module Resolvers
class BlobsResolver < BaseResolver
include Gitlab::Graphql::Authorize::AuthorizeResource
+ type Types::Snippets::BlobType.connection_type, null: true
+
alias_method :snippet, :object
argument :paths, [GraphQL::STRING_TYPE],
diff --git a/app/graphql/resolvers/todo_resolver.rb b/app/graphql/resolvers/todo_resolver.rb
index bd5f8f274cd..9a8f7a71154 100644
--- a/app/graphql/resolvers/todo_resolver.rb
+++ b/app/graphql/resolvers/todo_resolver.rb
@@ -2,7 +2,7 @@
module Resolvers
class TodoResolver < BaseResolver
- type Types::TodoType, null: true
+ type Types::TodoType.connection_type, null: true
alias_method :target, :object
diff --git a/app/graphql/resolvers/tree_resolver.rb b/app/graphql/resolvers/tree_resolver.rb
index 5aad1c71b40..075a1929c47 100644
--- a/app/graphql/resolvers/tree_resolver.rb
+++ b/app/graphql/resolvers/tree_resolver.rb
@@ -2,6 +2,8 @@
module Resolvers
class TreeResolver < BaseResolver
+ type Types::Tree::TreeType, null: true
+
argument :path, GraphQL::STRING_TYPE,
required: false,
default_value: '',
diff --git a/app/graphql/resolvers/users_resolver.rb b/app/graphql/resolvers/users_resolver.rb
index b0c1baa742d..f5838642141 100644
--- a/app/graphql/resolvers/users_resolver.rb
+++ b/app/graphql/resolvers/users_resolver.rb
@@ -4,6 +4,7 @@ module Resolvers
class UsersResolver < BaseResolver
include Gitlab::Graphql::Authorize::AuthorizeResource
+ type Types::UserType.connection_type, null: true
description 'Find Users'
argument :ids, [GraphQL::ID_TYPE],
diff --git a/app/models/design_management/version.rb b/app/models/design_management/version.rb
index 55c9084caf2..49aec8b9720 100644
--- a/app/models/design_management/version.rb
+++ b/app/models/design_management/version.rb
@@ -43,10 +43,7 @@ module DesignManagement
validates :sha, presence: true
validates :sha, uniqueness: { case_sensitive: false, scope: :issue_id }
validates :author, presence: true
- # We are not validating the issue object as it incurs an extra query to fetch
- # the record from the DB. Instead, we rely on the foreign key constraint to
- # ensure referential integrity.
- validates :issue_id, presence: true, unless: :importing?
+ validates :issue, presence: true, unless: :importing?
sha_attribute :sha
diff --git a/app/views/projects/pipelines/show.html.haml b/app/views/projects/pipelines/show.html.haml
index a25c30d01d9..0b07fe9921e 100644
--- a/app/views/projects/pipelines/show.html.haml
+++ b/app/views/projects/pipelines/show.html.haml
@@ -7,7 +7,7 @@
- add_page_specific_style 'page_bundles/ci_status'
.js-pipeline-container{ data: { controller_action: "#{controller.action_name}" } }
- #js-pipeline-header-vue.pipeline-header-container{ data: {full_path: @project.full_path, retry_path: retry_project_pipeline_path(@pipeline.project, @pipeline), cancel_path: cancel_project_pipeline_path(@pipeline.project, @pipeline), delete_path: project_pipeline_path(@pipeline.project, @pipeline), pipeline_iid: @pipeline.iid, pipeline_id: @pipeline.id} }
+ #js-pipeline-header-vue.pipeline-header-container{ data: { full_path: @project.full_path, pipeline_iid: @pipeline.iid, pipeline_id: @pipeline.id, pipelines_path: project_pipelines_path(@project) } }
- if @pipeline.commit.present?
= render "projects/pipelines/info", commit: @pipeline.commit
diff --git a/app/views/shared/wikis/_sidebar.html.haml b/app/views/shared/wikis/_sidebar.html.haml
index 893661755ab..c0ed7b4c6f2 100644
--- a/app/views/shared/wikis/_sidebar.html.haml
+++ b/app/views/shared/wikis/_sidebar.html.haml
@@ -1,7 +1,7 @@
%aside.right-sidebar.right-sidebar-expanded.wiki-sidebar.js-wiki-sidebar.js-right-sidebar{ data: { "offset-top" => "50", "spy" => "affix" } }
.sidebar-container
.block.wiki-sidebar-header.gl-mb-3.w-100
- %a.gutter-toggle.float-right.d-block.d-sm-block.d-md-none.js-sidebar-wiki-toggle{ href: "#" }
+ %a.gutter-toggle.float-right.d-block.d-md-none.js-sidebar-wiki-toggle{ href: "#" }
= sprite_icon('chevron-double-lg-right', css_class: 'gl-icon')
- if @wiki.container.is_a?(Project)
diff --git a/config/sidekiq_queues.yml b/config/sidekiq_queues.yml
index 2804322e029..2c1bb3c75e1 100644
--- a/config/sidekiq_queues.yml
+++ b/config/sidekiq_queues.yml
@@ -112,6 +112,8 @@
- 2
- - emails_on_push
- 2
+- - environments_canary_ingress_update
+ - 1
- - epics
- 2
- - error_tracking_issue_link
diff --git a/doc/.vale/gitlab/Substitutions.yml b/doc/.vale/gitlab/Substitutions.yml
index 704c64f1fbd..3d1cf8057eb 100644
--- a/doc/.vale/gitlab/Substitutions.yml
+++ b/doc/.vale/gitlab/Substitutions.yml
@@ -25,5 +25,13 @@ swap:
self hosted: self-managed
self-hosted: self-managed
styleguide: style guide
+ to login: to log in
+ can login: can log in
+ to log-in: to log in
+ can log-in: can log in
+ to signin: to sign in
+ can signin: can sign in
+ to sign-in: to sign in
+ can sign-in: can sign in
x509: X.509
yaml: YAML
diff --git a/doc/administration/auth/crowd.md b/doc/administration/auth/crowd.md
index 254bd259344..6e3dbcb68b3 100644
--- a/doc/administration/auth/crowd.md
+++ b/doc/administration/auth/crowd.md
@@ -82,6 +82,8 @@ If you see an error message like the one below when you sign in after Crowd auth
could not authorize you from Crowd because invalid credentials
```
-Please make sure the Crowd users who need to login to GitLab are authorized to [the application](#configure-a-new-crowd-application) in the step of **Authorisation**. This could be verified by try "Authentication test" for Crowd as of 2.11.
+Ensure the Crowd users who need to sign in to GitLab are authorized to the
+[application](#configure-a-new-crowd-application) in the **Authorisation** step.
+This could be verified by trying "Authentication test" for Crowd (as of 2.11).
![Example Crowd application authorisation configuration](img/crowd_application_authorisation.png)
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index 75cd411c586..9d88d66bf46 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -97,7 +97,8 @@ library. `start_tls` corresponds to StartTLS, not to be confused with regular TL
Normally, if you specify `simple_tls` it will be on port 636, while `start_tls` (StartTLS)
would be on port 389. `plain` also operates on port 389. Removed values: `tls` was replaced with `start_tls` and `ssl` was replaced with `simple_tls`.
-LDAP users must have an email address set, regardless of whether it is used to sign-in.
+LDAP users must have a set email address, regardless of whether or not it's used
+to sign in.
### Example Configurations **(CORE ONLY)**
@@ -444,10 +445,10 @@ account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
has bit 2 set.
For more information, see <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
-The user will be set to `ldap_blocked` state in GitLab if the above conditions
-fail. This means the user will not be able to sign-in or push/pull code.
+The user is set to an `ldap_blocked` state in GitLab if the previous conditions
+fail. This means the user won't be able to sign in or push/pull code.
-The process will also update the following user information:
+The process also updates the following user information:
- Email address.
- If `sync_ssh_keys` is set, SSH public keys.
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index c6558bf1791..089ff07af52 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -13,10 +13,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
#### Connection refused
-If you are getting `Connection Refused` errors when trying to connect to the
-LDAP server please double-check the LDAP `port` and `encryption` settings used by
-GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR
-`encryption: 'simple_tls'` and `port: 636`.
+If you're getting `Connection Refused` error messages when attempting to
+connect to the LDAP server, review the LDAP `port` and `encryption` settings
+used by GitLab. Common combinations are `encryption: 'plain'` and `port: 389`,
+or `encryption: 'simple_tls'` and `port: 636`.
#### Connection times out
@@ -103,16 +103,16 @@ A user can have trouble signing in for any number of reasons. To get started,
here are some questions to ask yourself:
- Does the user fall under the [configured `base`](index.md#configuration) in
- LDAP? The user must fall under this `base` to sign-in.
+ LDAP? The user must fall under this `base` to sign in.
- Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter)?
If one is not configured, this question can be ignored. If it is, then the
- user must also pass through this filter to be allowed to sign-in.
+ user must also pass through this filter to be allowed to sign in.
- Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
If the above are both okay, the next place to look for the problem is
the logs themselves while reproducing the issue.
-- Ask the user to sign-in and let it fail.
+- Ask the user to sign in and let it fail.
- [Look through the output](#gitlab-logs) for any errors or other
messages about the sign-in. You may see one of the other error messages on
this page, in which case that section can help resolve the issue.
@@ -159,7 +159,7 @@ The user should now be able to sign in.
#### Email has already been taken
-A user tries to sign-in with the correct LDAP credentials, is denied access,
+A user tries to sign in with the correct LDAP credentials, is denied access,
and the [production.log](../../logs.md#productionlog) shows an error that looks like this:
```plaintext
@@ -649,8 +649,7 @@ ldapsearch -D "cn=admin,dc=ldap-testing,dc=example,dc=com" \
Note that the `bind_dn`, `password`, `port`, `host`, and `base` are all
identical to what's configured in the `gitlab.rb`.
-Please see [the official
-`ldapsearch` documentation](https://linux.die.net/man/1/ldapsearch) for more.
+For more information, see the [official `ldapsearch` documentation](https://linux.die.net/man/1/ldapsearch).
### Using **AdFind** (Windows)
@@ -675,15 +674,15 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
### Rails console
CAUTION: **Caution:**
-Please note that it is very easy to create, read, modify, and destroy data on the
-rails console, so please be sure to run commands exactly as listed.
+It is very easy to create, read, modify, and destroy data with the rails
+console. Be sure to run commands exactly as listed.
The rails console is a valuable tool to help debug LDAP problems. It allows you to
directly interact with the application by running commands and seeing how GitLab
responds to them.
-Please refer to [this guide](../../operations/rails_console.md#starting-a-rails-console-session)
-for instructions on how to use the rails console.
+For instructions about how to use the rails console, refer to this
+[guide](../../operations/rails_console.md#starting-a-rails-console-session).
#### Enable debug output
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index 4ebc541b756..1e9b430834c 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -134,7 +134,10 @@ Note the following when promoting a secondary:
1. Promote the **secondary** node to the **primary** node.
DANGER: **Warning:**
- In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. This issue has been fixed in GitLab 13.4 or later.
+ In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the
+ secondary is paused fails. Do not pause replication before promoting a
+ secondary. If the node is paused, be sure to resume before promoting. This
+ issue has been fixed in GitLab 13.4 and later.
CAUTION: **Caution:**
If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
@@ -171,7 +174,10 @@ perform changes on a **secondary** with only a single machine. Instead, you must
do this manually.
DANGER: **Warning:**
-In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. This issue has been fixed in GitLab 13.4 or later.
+In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the
+secondary is paused fails. Do not pause replication before promoting a
+secondary. If the node is paused, be sure to resume before promoting. This
+issue has been fixed in GitLab 13.4 and later.
CAUTION: **Caution:**
If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
index daa13e52c0b..3864445bbf4 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
@@ -228,7 +228,10 @@ perform changes on a **secondary** with only a single machine. Instead, you must
do this manually.
DANGER: **Warning:**
-In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. This issue has been fixed in GitLab 13.4 or later.
+In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the
+secondary is paused fails. Do not pause replication before promoting a
+secondary. If the node is paused, be sure to resume before promoting. This
+issue has been fixed in GitLab 13.4 and later.
CAUTION: **Caution:**
If the secondary node [has been paused](../../../geo/index.md#pausing-and-resuming-replication), this performs
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index b9fffc9d4c2..8cecebee105 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -197,7 +197,10 @@ For information on how to update your Geo nodes to the latest GitLab version, se
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35913) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
DANGER: **Warning:**
-In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. This issue has been fixed in GitLab 13.4 or later.
+In GitLab 13.2 and 13.3, promoting a secondary node to a primary while the
+secondary is paused fails. Do not pause replication before promoting a
+secondary. If the node is paused, be sure to resume before promoting. This
+issue has been fixed in GitLab 13.4 and later.
CAUTION: **Caution:**
Pausing and resuming of replication is currently only supported for Geo installations using an
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 8c818bcfbe2..52f6e556dc4 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -229,8 +229,8 @@ replicating missing data from the **primary** node in a process known as **backf
Meanwhile, the **primary** node will start to notify each **secondary** node of any changes, so
that the **secondary** node can act on those notifications immediately.
-Make sure the **secondary** node is running and accessible.
-You can login to the **secondary** node with the same credentials as used for the **primary** node.
+Be sure the _secondary_ node is running and accessible. You can sign in to the
+_secondary_ node with the same credentials as were used with the _primary_ node.
### Step 4. Enabling Hashed Storage
@@ -262,10 +262,10 @@ method to be enabled. Navigate to **Admin Area > Settings**
Your **secondary** node is now configured!
-You can login to the **secondary** node with the same credentials you used for the
-**primary** node. Visit the **secondary** node's **Admin Area > Geo**
-(`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
-**secondary** Geo node and if Geo is enabled.
+You can sign in to the _secondary_ node with the same credentials you used with
+the _primary_ node. Visit the _secondary_ node's **Admin Area > Geo**
+(`/admin/geo/nodes`) in your browser to determine if it's correctly identified
+as a _secondary_ Geo node, and if Geo is enabled.
The initial replication, or 'backfill', will probably still be in progress. You
can monitor the synchronization process on each Geo node from the **primary**
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 8865fe95220..228f9f2cc21 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -164,7 +164,7 @@ replicating data from those features will cause the data to be **lost**.
If you wish to use those features on a **secondary** node, or to execute a failover
successfully, you must replicate their data using some other means.
-| Feature | Replicated (added in GitLab version) | Verified (added in GitLab version) | Object Storage replication (please see [Geo with Object Storage](object_storage.md)) | Notes |
+| Feature | Replicated (added in GitLab version) | Verified (added in GitLab version) | Object Storage replication (see [Geo with Object Storage](object_storage.md)) | Notes |
|:---------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------|:----------------------------------------------------------|:-------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Application data in PostgreSQL](../../postgresql/index.md) | **Yes** (10.2) | **Yes** (10.2) | No | |
| [Project repository](../../..//user/project/repository/) | **Yes** (10.2) | **Yes** (10.7) | No | |
diff --git a/doc/administration/geo/replication/location_aware_git_url.md b/doc/administration/geo/replication/location_aware_git_url.md
index ddcdea736e7..82fda8b0fc2 100644
--- a/doc/administration/geo/replication/location_aware_git_url.md
+++ b/doc/administration/geo/replication/location_aware_git_url.md
@@ -43,8 +43,8 @@ In any case, you require:
- A working GitLab **secondary** node.
- A Route53 Hosted Zone managing your domain.
-If you have not yet setup a Geo **primary** node and **secondary** node, please consult
-[the Geo setup instructions](../index.md#setup-instructions).
+If you haven't yet set up a Geo _primary_ node and _secondary_ node, see the
+[Geo setup instructions](../index.md#setup-instructions).
## Create a traffic policy
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index 642d31f6298..3f5ba1939b8 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -72,7 +72,7 @@ If you are using Google Cloud Storage, consider using
Or you can use the [Storage Transfer Service](https://cloud.google.com/storage-transfer/docs/),
although this only supports daily synchronization.
-For manual synchronization, or scheduled by `cron`, please have a look at:
+For manual synchronization, or scheduled by `cron`, see:
- [`s3cmd sync`](https://s3tools.org/s3cmd-sync)
- [`gsutil rsync`](https://cloud.google.com/storage/docs/gsutil/commands/rsync)
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index e60b9567c6f..15e3d3ff0a8 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -720,7 +720,8 @@ GitLab cannot find or doesn't have permission to access the `database_geo.yml` c
In an Omnibus GitLab installation, the file should be in `/var/opt/gitlab/gitlab-rails/etc`.
If it doesn't exist or inadvertent changes have been made to it, run `sudo gitlab-ctl reconfigure` to restore it to its correct state.
-If this path is mounted on a remote volume, please check your volume configuration and that it has correct permissions.
+If this path is mounted on a remote volume, ensure your volume configuration
+has the correct permissions.
### An existing tracking database cannot be reused
diff --git a/doc/administration/geo/replication/updating_the_geo_nodes.md b/doc/administration/geo/replication/updating_the_geo_nodes.md
index 55ddccb1d98..af59e45250c 100644
--- a/doc/administration/geo/replication/updating_the_geo_nodes.md
+++ b/doc/administration/geo/replication/updating_the_geo_nodes.md
@@ -8,7 +8,9 @@ type: howto
# Updating the Geo nodes **(PREMIUM ONLY)**
CAUTION: **Warning:**
-Please ensure you read these sections carefully before updating your Geo nodes! Not following version-specific update steps may result in unexpected downtime. Please [contact support](https://about.gitlab.com/support/#contact-support) if you have any specific questions.
+Read these sections carefully before updating your Geo nodes. Not following
+version-specific update steps may result in unexpected downtime. If you have
+any specific questions, [contact Support](https://about.gitlab.com/support/#contact-support).
Updating Geo nodes involves performing:
@@ -47,4 +49,4 @@ everything is working correctly:
1. Test the data replication by pushing code to the **primary** node and see if it
is received by **secondary** nodes.
-If you encounter any issues, please consult the [Geo troubleshooting guide](troubleshooting.md).
+If you encounter any issues, see the [Geo troubleshooting guide](troubleshooting.md).
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md
index e01c60c0925..abb9bf05ceb 100644
--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -25,40 +25,43 @@ DROP EXTENSION IF EXISTS postgres_fdw;
```
DANGER: **Warning:**
-In GitLab 13.3, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. To avoid this issue, upgrade to GitLab 13.4 or later.
+In GitLab 13.3, promoting a secondary node to a primary while the secondary is
+paused fails. Do not pause replication before promoting a secondary. If the
+node is paused, be sure to resume before promoting. To avoid this issue,
+upgrade to GitLab 13.4 or later.
## Updating to GitLab 13.2
-In GitLab 13.2, promoting a secondary node to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the node is paused, please resume before promoting. To avoid this issue, upgrade to GitLab 13.4 or later.
+In GitLab 13.2, promoting a secondary node to a primary while the secondary is
+paused fails. Do not pause replication before promoting a secondary. If the
+node is paused, be sure to resume before promoting. To avoid this issue,
+upgrade to GitLab 13.4 or later.
## Updating to GitLab 13.0
Upgrading to GitLab 13.0 requires GitLab 12.10 to already be using PostgreSQL
-version 11. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+version 11. For the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Updating to GitLab 12.10
-GitLab 12.10 does not attempt to automatically update the embedded PostgreSQL
-server when using Geo, because the PostgreSQL upgrade requires downtime on
-secondaries while reinitializing streaming replication. It must be upgraded
-manually. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+GitLab 12.10 doesn't attempt to update the embedded PostgreSQL server when
+using Geo, because the PostgreSQL upgrade requires downtime for secondaries
+while reinitializing streaming replication. It must be upgraded manually. For
+the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Updating to GitLab 12.9
CAUTION: **Warning:**
GitLab 12.9.0 through GitLab 12.9.3 are affected by [a bug that stops
repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
-The issue is fixed in GitLab 12.9.4. Please upgrade to GitLab 12.9.4 or later.
+The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
By default, GitLab 12.9 will attempt to automatically update the embedded
PostgreSQL server to 10.12 from 9.6, which requires downtime on secondaries
-while reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+while reinitializing streaming replication. For the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -70,9 +73,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
By default, GitLab 12.8 will attempt to automatically update the embedded
PostgreSQL server to 10.12 from 9.6, which requires downtime on secondaries
-while reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+while reinitializing streaming replication. For the recommended procedure, see
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -91,10 +93,9 @@ fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24021) was
shipped in 12.7.5.
By default, GitLab 12.7 will attempt to automatically update the embedded
-PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries while
-reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries
+while reinitializing streaming replication. For the recommended procedure, see
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -105,10 +106,9 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
## Updating to GitLab 12.6
By default, GitLab 12.6 will attempt to automatically update the embedded
-PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries while
-reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries
+while reinitializing streaming replication. For the recommended procedure, see
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -119,10 +119,9 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
## Updating to GitLab 12.5
By default, GitLab 12.5 will attempt to automatically update the embedded
-PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries while
-reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries
+while reinitializing streaming replication. For the recommended procedure, see
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -133,10 +132,9 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
## Updating to GitLab 12.4
By default, GitLab 12.4 will attempt to automatically update the embedded
-PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries while
-reinitializing streaming replication. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+PostgreSQL server to 10.9 from 9.6, which requires downtime on secondaries
+while reinitializing streaming replication. For the recommended procedure, see
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
This can be temporarily disabled by running the following before updating:
@@ -148,33 +146,29 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
DANGER: **Warning:**
If the existing PostgreSQL server version is 9.6.x, it is recommended to
-upgrade to GitLab 12.4 or newer. By default, GitLab 12.3 will attempt to
-automatically update the embedded PostgreSQL server to 10.9 from 9.6. In
-certain circumstances, it will fail. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for more information.
+upgrade to GitLab 12.4 or later. By default, GitLab 12.3 attempts to update the
+embedded PostgreSQL server from 9.6 to 10.9. In certain circumstances, it will
+fail. For more information, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-Additionally, if the PostgreSQL upgrade does not fail, a successful upgrade
-requires downtime on secondaries while reinitializing streaming replication.
-Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
+requires downtime for secondaries while reinitializing streaming replication.
+For the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Updating to GitLab 12.2
DANGER: **Warning:**
If the existing PostgreSQL server version is 9.6.x, it is recommended to
-upgrade to GitLab 12.4 or newer. By default, GitLab 12.2 will attempt to
-automatically update the embedded PostgreSQL server to 10.9 from 9.6. In
-certain circumstances, it will fail. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for more information.
+upgrade to GitLab 12.4 or later. By default, GitLab 12.2 attempts to update the
+embedded PostgreSQL server from 9.6 to 10.9. In certain circumstances, it will
+fail. For more information, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
Additionally, if the PostgreSQL upgrade does not fail, a successful upgrade
-requires downtime on secondaries while reinitializing streaming replication.
-Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+requires downtime for secondaries while reinitializing streaming replication.
+For the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
GitLab 12.2 includes the following minor PostgreSQL updates:
@@ -196,31 +190,29 @@ The restart avoids a version mismatch when PostgreSQL tries to load the FDW exte
DANGER: **Warning:**
If the existing PostgreSQL server version is 9.6.x, it is recommended to
-upgrade to GitLab 12.4 or newer. By default, GitLab 12.1 will attempt to
-automatically update the embedded PostgreSQL server to 10.9 from 9.6. In
-certain circumstances, it will fail. Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for more information.
+upgrade to GitLab 12.4 or later. By default, GitLab 12.1 attempts to update the
+embedded PostgreSQL server from 9.6 to 10.9. In certain circumstances, it will
+fail. For more information, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-Additionally, if the PostgreSQL upgrade does not fail, a successful upgrade
-requires downtime on secondaries while reinitializing streaming replication.
-Please see
-[the Omnibus documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance)
-for the recommended procedure.
+Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
+requires downtime for secondaries while reinitializing streaming replication.
+For the recommended procedure, see the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Updating to GitLab 12.0
CAUTION: **Warning:**
-This version is affected by [a bug that results in new LFS objects not being replicated to
-Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696). The issue is fixed
-in GitLab 12.1. Please upgrade to GitLab 12.1 or later.
+This version is affected by a [bug that results in new LFS objects not being
+replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
+The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
## Updating to GitLab 11.11
CAUTION: **Warning:**
-This version is affected by [a bug that results in new LFS objects not being replicated to
-Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696). The issue is fixed
-in GitLab 12.1. Please upgrade to GitLab 12.1 or later.
+This version is affected by a [bug that results in new LFS objects not being
+replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
+The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
## Updating to GitLab 10.8
@@ -440,7 +432,7 @@ required because replication slots are used by default. However, if you
started with GitLab 9.3 and updated later, you should still follow the
instructions below.
-When in doubt, it does not hurt to do a resync. The easiest way to do this in
+When in doubt, it doesn't hurt to do a resync. The easiest way to do this in
Omnibus is the following:
1. Make sure you have Omnibus GitLab on the **primary** server.
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index 6003b9921f8..3e16b173003 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -249,9 +249,9 @@ gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'
```
-Run `sudo gitlab-ctl reconfigure` to start using the central location. Please
-be aware that if you had existing data you will need to manually copy/rsync it
-to these new locations and then restart GitLab.
+Run `sudo gitlab-ctl reconfigure` to start using the central location. Be aware
+that if you had existing data, you'll need to manually copy or rsync it to
+these new locations, and then restart GitLab.
### Bind mounts
@@ -399,8 +399,8 @@ Additionally, this configuration is specifically warned against in the
>system semantics, this can cause reliability problems. Specifically, delayed (asynchronous) writes
>to the NFS server can cause data corruption problems.
-For supported database architecture, please see our documentation on
-[Configuring a Database for GitLab HA](postgresql/replication_and_failover.md).
+For supported database architecture, see our documentation about
+[configuring a database for replication and failover](postgresql/replication_and_failover.md).
<!-- ## Troubleshooting
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 88ef69b29f2..c8830a45fb2 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -196,7 +196,8 @@ the database. The following instructions can be used to build OpenSSH 7.5:
yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
```
-1. Verify the installed version. In another window, attempt to login to the server:
+1. Verify the installed version. In another window, attempt to sign in to the
+ server:
```shell
ssh -v <your-centos-machine>
@@ -204,7 +205,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
- If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
+ If not, you may need to restart `sshd` (for example, `systemctl restart sshd.service`).
1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
sure everything is working! If you need to downgrade, simple install the
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 5335af1a807..49ef9385167 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -170,7 +170,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
-Users should now be able to login to the Container Registry with their GitLab
+Users should now be able to sign in to the Container Registry with their GitLab
credentials using:
```shell
@@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
-Users should now be able to login to the Container Registry using their GitLab
+Users should now be able to sign in to the Container Registry using their GitLab
credentials:
```shell
@@ -1234,8 +1234,8 @@ This will launch the Docker daemon and proxy all connections through mitmproxy.
#### Running the Docker client
-Now that we have mitmproxy and Docker running, we can attempt to login and push
-a container image. You may need to run as root to do this. For example:
+Now that we have mitmproxy and Docker running, we can attempt to sign in and
+push a container image. You may need to run as root to do this. For example:
```shell
docker login s3-testing.myregistry.com:5050
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index 0b3a7ae9fa5..e2809e7fc35 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -12,20 +12,44 @@ packages, which can be easily consumed as a dependency in downstream projects.
The Packages feature allows GitLab to act as a repository for the following:
-| Software repository | Description | Available in GitLab version |
-| ------------------- | ----------- | --------------------------- |
-| [PyPI Repository](../../user/packages/pypi_repository/index.md) | The GitLab PyPI Repository enables every project in GitLab to have its own space to store [PyPI](https://pypi.org/) packages. | 12.10+ |
-| [Composer Repository](../../user/packages/composer_repository/index.md) | The GitLab Composer Repository enables every project in GitLab to have its own space to store [Composer](https://getcomposer.org/) packages. | 13.1+ |
-| [NuGet Repository](../../user/packages/nuget_repository/index.md) | The GitLab NuGet Repository enables every project in GitLab to have its own space to store [NuGet](https://www.nuget.org/) packages. | 12.8+ |
-| [Conan Repository](../../user/packages/conan_repository/index.md) | The GitLab Conan Repository enables every project in GitLab to have its own space to store [Conan](https://conan.io/) packages. | 12.4+ |
-| [Maven Repository](../../user/packages/maven_repository/index.md) | The GitLab Maven Repository enables every project in GitLab to have its own space to store [Maven](https://maven.apache.org/) packages. | 11.3+ |
-| [NPM Registry](../../user/packages/npm_registry/index.md) | The GitLab NPM Registry enables every project in GitLab to have its own space to store [NPM](https://www.npmjs.com/) packages. | 11.7+ |
-| [Go Proxy](../../user/packages/go_proxy/index.md) | The Go proxy for GitLab enables every project in GitLab to be fetched with the [Go proxy protocol](https://proxy.golang.org/). | 13.1+ |
-| [Generic packages](../../user/packages/generic_packages/index.md) | Store arbitrary files, like release binaries. | 13.5+ |
-
-Don't you see your package management system supported yet?
-Please consider contributing
-to GitLab. This [development documentation](../../development/packages.md) will guide you through the process.
+The Package Registry supports the following formats:
+
+<div class="row">
+<div class="col-md-9">
+<table align="left" style="width:50%">
+<tr style="background:#dfdfdf"><th>Package type</th><th>GitLab version</th></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/composer_repository/index.html">Composer</a></td><td>13.2+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/conan_repository/index.html">Conan</a></td><td>12.6+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/go_proxy/index.html">Go</a></td><td>13.1+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/maven_repository/index.html">Maven</a></td><td>11.3+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/npm_registry/index.html">NPM</a></td><td>11.7+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/nuget_repository/index.html">NuGet</a></td><td>12.8+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/pypi_repository/index.html">PyPI</a></td><td>12.10+</td></tr>
+<tr><td><a href="https://docs.gitlab.com/ee/user/packages/generic_packages/index.html">Generic packages</a></td><td>13.5+</td></tr>
+</table>
+</div>
+</div>
+
+## Accepting contributions
+
+The below table lists formats that are not supported, but are accepting Community contributions for. Consider contributing to GitLab. This [development documentation](../../development/packages.md) will
+guide you through the process.
+
+| Format | Status |
+| ------ | ------ |
+| Chef | [#36889](https://gitlab.com/gitlab-org/gitlab/-/issues/36889) |
+| CocoaPods | [#36890](https://gitlab.com/gitlab-org/gitlab/-/issues/36890) |
+| Conda | [#36891](https://gitlab.com/gitlab-org/gitlab/-/issues/36891) |
+| CRAN | [#36892](https://gitlab.com/gitlab-org/gitlab/-/issues/36892) |
+| Debian | [WIP: Merge Request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44746) |
+| Opkg | [#36894](https://gitlab.com/gitlab-org/gitlab/-/issues/36894) |
+| P2 | [#36895](https://gitlab.com/gitlab-org/gitlab/-/issues/36895) |
+| Puppet | [#36897](https://gitlab.com/gitlab-org/gitlab/-/issues/36897) |
+| RPM | [#5932](https://gitlab.com/gitlab-org/gitlab/-/issues/5932) |
+| RubyGems | [#803](https://gitlab.com/gitlab-org/gitlab/-/issues/803) |
+| SBT | [#36898](https://gitlab.com/gitlab-org/gitlab/-/issues/36898) |
+| Terraform | [WIP: Merge Request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18834) |
+| Vagrant | [#36899](https://gitlab.com/gitlab-org/gitlab/-/issues/36899) |
## Enabling the Packages feature
@@ -58,6 +82,18 @@ To enable the Packages feature:
1. [Restart GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab") for the changes to take effect.
+**Helm Chart installations**
+
+1. After the installation is complete, you will have to configure the `packages`
+ section in `global.appConfig.packages`. Set to `true` to enable it:
+
+ ```yaml
+ packages:
+ enabled: true
+ ```
+
+1. [Restart GitLab](../restart_gitlab.md#helm-chart-installations "How to reconfigure Helm GitLab") for the changes to take effect.
+
## Changing the storage path
By default, the packages are stored locally, but you can change the default
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 0a40b61fd3c..a29815672e5 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -579,18 +579,19 @@ in the Troubleshooting section before proceeding.
### Ensure GitLab is running
-At this point, your GitLab instance should be up and running. Verify you are
-able to login, and create issues and merge requests. If you have troubles check
+At this point, your GitLab instance should be up and running. Verify you're able
+to sign in, and create issues and merge requests. If you encounter issues, see
the [Troubleshooting section](#troubleshooting).
## Example configuration
-Here we'll show you some fully expanded example configurations.
+This section describes several fully expanded example configurations.
### Example recommended setup
-This example uses 3 Consul servers, 3 PgBouncer servers (with associated internal load balancer),
-3 PostgreSQL servers, and 1 application node.
+This example uses three Consul servers, three PgBouncer servers (with an
+associated internal load balancer), three PostgreSQL servers, and one
+application node.
We start with all servers on the same 10.6.0.0/16 private network range, they
can connect to each freely other on those addresses.
diff --git a/doc/administration/reply_by_email.md b/doc/administration/reply_by_email.md
index 2b57e9f3e88..de19c025cb4 100644
--- a/doc/administration/reply_by_email.md
+++ b/doc/administration/reply_by_email.md
@@ -46,4 +46,4 @@ If it finds a reply key, it will be able to leave your reply as a comment on
the entity the notification was about (issue, merge request, commit...).
For more details about the `Message-ID`, `In-Reply-To`, and `References headers`,
-please consult [RFC 5322](https://tools.ietf.org/html/rfc5322#section-3.6.4).
+see [RFC 5322](https://tools.ietf.org/html/rfc5322#section-3.6.4).
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index f7d54aa7d78..b4aa8daacc6 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -561,10 +561,11 @@ See below for examples of each.
#### Determining your `DOCKER_AUTH_CONFIG` data
-As an example, let's assume that you want to use the `registry.example.com:5000/private/image:latest`
-image which is private and requires you to login into a private container registry.
+As an example, let's assume you want to use the `registry.example.com:5000/private/image:latest`
+image, which is private and requires you to sign in to a private container
+registry.
-Let's also assume that these are the login credentials:
+Let's also assume that these are the sign-in credentials:
| Key | Value |
|:---------|:----------------------------|
@@ -572,9 +573,9 @@ Let's also assume that these are the login credentials:
| username | `my_username` |
| password | `my_password` |
-There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
+Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
-- **First way -** Do a `docker login` on your local machine:
+- Do a `docker login` on your local machine:
```shell
docker login registry.example.com:5000 --username my_username --password my_password
@@ -589,12 +590,11 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
docker logout registry.example.com:5000
```
-- **Second way -** In some setups, it's possible that Docker client
- uses the available system key store to store the result of `docker
- login`. In that case, it's impossible to read `~/.docker/config.json`,
- so you need to prepare the required base64-encoded version of
- `${username}:${password}` and create the Docker configuration JSON manually.
- Open a terminal and execute the following command:
+- In some setups, it's possible that Docker client uses the available system key
+ store to store the result of `docker login`. In that case, it's impossible to
+ read `~/.docker/config.json`, so you need to prepare the required
+ base64-encoded version of `${username}:${password}` and create the Docker
+ configuration JSON manually. Open a terminal and execute the following command:
```shell
# The use of "-n" - prevents encoding a newline in the password.
diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
index 9156f53c7b3..25b866a08ed 100644
--- a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
+++ b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
@@ -103,27 +103,27 @@ Hub](https://hub.docker.com/). We've also added the [`only`
clause](../../yaml/README.md#onlyexcept-basic)
to ensure our deployments only happen when we push to the master branch.
-Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
-to CF, you'll need to add your CF credentials as [environment
-variables](../../variables/README.md#predefined-environment-variables)
-on GitLab CI/CD. To set the environment variables, navigate to your project's
-**Settings > CI/CD** and expand **Variables**. Name the variables
+Because the steps defined in `.gitlab-ci.yml` require credentials to sign in to
+CF, you'll need to add your CF credentials as
+[environment variables](../../variables/README.md#predefined-environment-variables)
+in GitLab CI/CD. To set the environment variables, navigate to your project's
+**Settings > CI/CD**, and then expand **Variables**. Name the variables
`CF_USERNAME` and `CF_PASSWORD` and set them to the correct values.
![Variable Settings in GitLab](img/cloud_foundry_variables.png)
-Once set up, GitLab CI/CD will deploy your app to CF at every push to your
-repository's default branch. To see the build logs or watch your builds running
-live, navigate to **CI/CD > Pipelines**.
+After set up, GitLab CI/CD deploys your app to CF at every push to your
+repository's default branch. To review the build logs or watch your builds
+running live, navigate to **CI/CD > Pipelines**.
CAUTION: **Caution:**
-It is considered best practice for security to create a separate deploy
-user for your application and add its credentials to GitLab instead of using
-a developer's credentials.
+It's considered best practice for security to create a separate deploy user for
+your application and add its credentials to GitLab instead of using a
+developer's credentials.
To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
-on **Run Pipeline**. After the app is finished deploying it will display the URL
-of your application in the logs for the `production` job like:
+on **Run Pipeline**. After the app is finished deploying, it will display the
+URL of your application in the logs for the `production` job like:
```shell
requested state: started
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 908193ebb2e..864dfdf3484 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -697,7 +697,9 @@ To configure markdownlint within your editor, install one of the following as ap
To configure Vale within your editor, install one of the following as appropriate:
- The Sublime Text [`SublimeLinter-contrib-vale` plugin](https://packagecontrol.io/packages/SublimeLinter-contrib-vale).
-- The Visual Studio Code [`errata-ai.vale-server` extension](https://marketplace.visualstudio.com/items?itemName=errata-ai.vale-server). You don't need Vale Server to use the plugin.
+- The Visual Studio Code [`errata-ai.vale-server` extension](https://marketplace.visualstudio.com/items?itemName=errata-ai.vale-server).
+ You don't need Vale Server to use the plugin. You can configure the plugin to
+ [display only a subset of alerts](#show-subset-of-vale-alerts).
- [Vim](https://github.com/dense-analysis/ale).
We don't use [Vale Server](https://errata-ai.github.io/vale/#using-vale-with-a-text-editor-or-another-third-party-application).
@@ -717,6 +719,23 @@ file for the [`gitlab`](https://gitlab.com/gitlab-org/gitlab) project.
To set up `lefthook` for documentation linting, see
[Pre-push static analysis](../contributing/style_guides.md#pre-push-static-analysis).
+#### Show subset of Vale alerts
+
+You can set Visual Studio Code to display only a subset of Vale alerts when viewing files:
+
+1. Go to **Preferences > Settings > Extensions > Vale**.
+1. In **Vale CLI: Min Alert Level**, select the minimum alert level you want displayed in files.
+
+To display only a subset of Vale alerts when running Vale from the command line, use
+the `--minAlertLevel` flag, which accepts `error`, `warning`, or `suggestion`. Combine it with `--config`
+to point to the configuration file within the project, if needed:
+
+```shell
+vale --config .vale.ini --minAlertLevel error doc/**/*.md
+```
+
+Omit the flag to display all alerts, including `suggestion` level alerts.
+
#### Disable Vale tests
You can disable a specific Vale linting rule or all Vale linting rules for any portion of a
diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
index af7ea210edb..df4b833526c 100644
--- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
+++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
@@ -238,7 +238,11 @@ run: ./services/tunnel_gitlab: (pid 2650) 10875s, normally down; run: log: (pid
run: ./services/tunnel_registry: (pid 2651) 10875s, normally down; run: log: (pid 65155) 177993s
```
-Also, restarting Docker and then, on the Terminal, issue the command `docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use the GDK credentials to login. Note that the Registry port and GDK port are not the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command outputs the port of the Registry:
+Also, restarting Docker and then, on the Terminal, issue the command
+`docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use
+the GDK credentials to sign in. Note that the Registry port and GDK port aren't
+the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command
+outputs the port of the Registry:
```shell
*********************************************
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index b5e72a9b84a..9dc30ab2476 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -347,8 +347,8 @@ connect to it using SSH ([Secure Shell](https://en.wikipedia.org/wiki/Secure_She
If you're running Windows, you'll need to connect using [PuTTY](https://www.putty.org) or an equivalent Windows SSH client.
If you're running Linux or macOS, then you already have an SSH client installed.
-Remember that you will need to login with the username and password you specified
-[when you created](#basics) your Azure VM.
+Remember to sign in with the username and password you specified when you
+[created your Azure VM](#basics).
If you need to reset your VM password, read
[how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
@@ -375,20 +375,20 @@ read on [using PuTTY in Windows](https://mediatemple.net/community/products/dv/2
### Updating GitLab
-Once you've logged in via SSH, enter the following command to update GitLab to the latest
-version:
+After signing in by using SSH, enter the following command to update GitLab to
+the latest version:
```shell
sudo apt-get update && sudo apt-get install gitlab-ce
```
-This command will update GitLab and its associated components to the latest versions, so it will
-take a little time to complete. You'll see various update tasks being completed in your SSH
-terminal window:
+This command updates GitLab and its associated components to the latest versions,
+so it will take a little time to complete. You'll see various update tasks being
+completed in your SSH terminal window:
![GitLab updating](img/gitlab-ssh-update-in-progress.png)
-Once the update process has completed, you'll see a message like this:
+After the update process is complete, you'll see a message like this:
```plaintext
Upgrade complete! If your GitLab server is misbehaving try running
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index 7ac5aa6667a..2d7389a48a0 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -183,9 +183,9 @@ Using the all-in-one VM gives you the ability to test OpenShift whenever you
want. That means you get to play with it, shutdown the VM, and pick up where
you left off.
-Sometimes though, you may encounter some issues, like OpenShift not running
-when booting up the VM. The web UI may not responding or you may see issues
-when trying to login with `oc`, like:
+Occasionally, you may encounter issues, like OpenShift not running when booting
+up the VM. The web UI may not respond, or you may see issues when trying to sign
+in with `oc`, like:
```plaintext
The connection to the server 10.2.2.2:8443 was refused - did you specify the right host or port?
@@ -213,8 +213,7 @@ In that case, the OpenShift service might not be running, so in order to fix it:
systemctl status openshift -l
```
-Now you will be able to login using `oc` (like we did before) and visit the web
-console.
+You can now sign in by using `oc` (like we did before) and visit the web console.
## Deploy GitLab
@@ -497,14 +496,13 @@ oc adm policy add-scc-to-user anyuid system:serviceaccount:gitlab:gitlab-ce-user
## Conclusion
-By now, you should have an understanding of the basic OpenShift Origin concepts
-and a sense of how things work using the web console or the CLI.
+You should now have an understanding of the basic OpenShift Origin concepts, and
+a sense of how things work using the web console or the CLI.
-GitLab was hard to install in previous versions of OpenShift,
-but now that belongs to the past. Upload a template, create a project, add an
-application and you are done. You are ready to login to your new GitLab instance.
+Upload a template, create a project, add an application, and you're done. You're
+ready to sign in to your new GitLab instance.
-And remember that in this tutorial we just scratched the surface of what Origin
-is capable of. As always, you can refer to the detailed
-[documentation](https://docs.okd.io) to learn more about deploying your own OpenShift
-PaaS and managing your applications with the ease of containers.
+Remember that this tutorial doesn't address all that Origin is capable of. As
+always, refer to the detailed [documentation](https://docs.okd.io) to learn more
+about deploying your own OpenShift PaaS and managing your applications with
+containers.
diff --git a/doc/integration/github.md b/doc/integration/github.md
index cff919c902a..8407920c631 100644
--- a/doc/integration/github.md
+++ b/doc/integration/github.md
@@ -6,7 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Integrate your GitLab instance with GitHub
-You can integrate your GitLab instance with GitHub.com as well as GitHub Enterprise to enable users to import projects from GitHub and/or to login to your GitLab instance with your GitHub account.
+You can integrate your GitLab instance with GitHub.com and GitHub Enterprise to
+enable users to import projects from GitHub or sign in to your GitLab instance
+with your GitHub account.
## Enabling GitHub OAuth
@@ -24,11 +26,11 @@ See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
Once you have configured the GitHub provider, you'll need the following information, which you'll need to substitute in the GitLab configuration file, in the steps shown next.
-| Setting from GitHub | Substitute in the GitLab configuration file | Description |
-|:---------------------|:-----------------------------------------------|:------------|
-| Client ID | `YOUR_APP_ID` | OAuth 2 Client ID |
-| Client Secret | `YOUR_APP_SECRET` | OAuth 2 Client Secret |
-| URL | `https://github.example.com/` | GitHub Deployment URL |
+| Setting from GitHub | Substitute in the GitLab configuration file | Description |
+|:---------------------|:---------------------------------------------|:------------|
+| Client ID | `YOUR_APP_ID` | OAuth 2 Client ID |
+| Client Secret | `YOUR_APP_SECRET` | OAuth 2 Client Secret |
+| URL | `https://github.example.com/` | GitHub Deployment URL |
Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 4efca8c32de..316db57c7cc 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -96,18 +96,17 @@ to authenticate with Kerberos tokens.
The Administrative user can navigate to **Admin > Users > Example User > Identities**
and attach a Kerberos account. Existing GitLab users can go to **Profile > Account**
and attach a Kerberos account. If you want to allow users without a GitLab
-account to login, you should enable the option `allow_single_sign_on` as
-described in the [Configure GitLab](#configure-gitlab) section. Then, the first
-time a user signs in with Kerberos credentials, GitLab will create a new GitLab
-user associated with the email, which is built from the Kerberos username and
-realm. User accounts will be created automatically when authentication was
-successful.
+account to sign in, enable the `allow_single_sign_on` option, as described in the
+[Configure GitLab](#configure-gitlab) section. The first time a user signs in
+with Kerberos credentials, GitLab will create a new GitLab user associated with
+the email, which is built from the Kerberos username and realm. User accounts are
+created after successful authentications.
## Linking Kerberos and LDAP accounts together
-If your users log in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
-enabled, then your users will be automatically linked to their LDAP accounts on
-first login. For this to work, some prerequisites must be met:
+If your users sign in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
+enabled, your users will be linked to their LDAP accounts on their first sign-in.
+For this to work, some prerequisites must be met:
The Kerberos username must match the LDAP user's UID. You can choose which LDAP
attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration)
@@ -125,10 +124,10 @@ LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9962) in GitLab 13.5.
-You can configure custom allowed realms when
-the user's Kerberos realm doesn't match the domain from the user's LDAP DN. The
-configuration value must specify all domains that users may be expected to
-have. Any other domains will be ignored and an LDAP identity will not be linked.
+You can configure custom allowed realms when the user's Kerberos realm doesn't
+match the domain from the user's LDAP DN. The configuration value must specify
+all domains that users may be expected to have. Any other domains will be
+ignored and an LDAP identity won't be linked.
**For Omnibus installations**
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index 535f97e9a4d..eebafab2693 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -88,8 +88,8 @@ To change these settings:
```ruby
# CAUTION!
- # This allows users to login without having a user account first. Define the allowed providers
- # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
+ # This allows users to sign in without having a user account first. Define the allowed providers
+ # using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
gitlab_rails['omniauth_auto_link_ldap_user'] = true
@@ -111,13 +111,13 @@ To change these settings:
```yaml
## OmniAuth settings
omniauth:
- # Allow login via Twitter, Google, etc. using OmniAuth providers
+ # Allow sign-in by using Twitter, Google, etc. using OmniAuth providers
# Versions prior to 11.4 require this to be set to true
# enabled: true
# CAUTION!
- # This allows users to login without having a user account first. Define the allowed providers
- # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
+ # This allows users to sign in without having a user account first. Define the allowed providers
+ # using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
allow_single_sign_on: ["saml", "twitter"]
@@ -177,9 +177,9 @@ like `google_oauth2` for Google. Refer to the examples for the full names of the
supported providers.
NOTE: **Note:**
-If you decide to remove an OmniAuth provider from the external providers list
-you will need to manually update the users that use this method to login, if you
-want their accounts to be upgraded to full internal accounts.
+If you decide to remove an OmniAuth provider from the external providers list,
+you must manually update the users that use this method to sign in if you want
+their accounts to be upgraded to full internal accounts.
**For Omnibus installations**
@@ -302,13 +302,13 @@ omniauth:
## Bypassing two factor authentication
-Starting with GitLab 12.3, this allows users to login with the specified
-providers without two factor authentication.
+In GitLab 12.3 or later, users can sign in with specified providers _without_
+using two factor authentication.
-Define the allowed providers using an array, e.g. `["twitter", 'google_oauth2']`, or as
-`true`/`false` to allow all providers or none. This option should only be configured
-for providers which already have two factor authentication (default: false).
-This configuration dose not apply to SAML.
+Define the allowed providers using an array (for example, `["twitter", 'google_oauth2']`),
+or as `true` or `false` to allow all providers (or none). This option should be
+configured only for providers which already have two factor authentication
+(default: false). This configuration doesn't apply to SAML.
```ruby
gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']
@@ -323,13 +323,12 @@ omniauth:
## Automatically sign in with provider
-You can add the `auto_sign_in_with_provider` setting to your
-GitLab configuration to automatically redirect login requests
-to your OmniAuth provider for authentication, thus removing the need to click a button
-before actually signing in.
+You can add the `auto_sign_in_with_provider` setting to your GitLab
+configuration to redirect login requests to your OmniAuth provider for
+authentication, removing the need to click a button before actually signing in.
-For example, when using the Azure integration, you would set the following
-to enable auto sign in.
+For example, when using the Azure integration, set the following to enable auto
+sign-in:
For Omnibus package:
@@ -344,13 +343,15 @@ omniauth:
auto_sign_in_with_provider: azure_oauth2
```
-Please keep in mind that every sign in attempt will be redirected to the OmniAuth provider,
-so you will not be able to sign in using local credentials. Make sure that at least one
-of the OmniAuth users has admin permissions.
+Keep in mind that every sign-in attempt will be redirected to the OmniAuth
+provider; you won't be able to sign in using local credentials. Ensure at least
+one of the OmniAuth users has admin permissions.
-You may also bypass the auto signin feature by browsing to
+You may also bypass the auto sign in feature by browsing to
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
## Passwords for users created via OmniAuth
-The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via OmniAuth.
+The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md)
+guide provides an overview about how GitLab generates and sets passwords for
+users created with OmniAuth.
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index ac649e48c1a..16a33a86472 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -369,18 +369,18 @@ omniauth:
auto_sign_in_with_provider: saml
```
-Please keep in mind that every sign in attempt will be redirected to the SAML server,
-so you will not be able to sign in using local credentials. Make sure that at least one
-of the SAML users has admin permissions.
+Keep in mind that every sign in attempt will be redirected to the SAML server;
+you won't be able to sign in using local credentials. Ensure at least one of the
+SAML users has admin permissions.
-You may also bypass the auto signin feature by browsing to
+You may also bypass the auto sign-in feature by browsing to
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
### `attribute_statements`
NOTE: **Note:**
-This setting should only be used to map attributes that are part of the
-OmniAuth `info` hash schema.
+This setting should be used only to map attributes that are part of the OmniAuth
+`info` hash schema.
`attribute_statements` is used to map Attribute Names in a SAMLResponse to entries
in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
@@ -541,9 +541,14 @@ This integration uses the `certificate` and `private_key` settings for both asse
## Request signing (optional)
-Another optional configuration is to sign SAML authentication requests. GitLab SAML Requests uses the SAML redirect binding so this is not necessary, unlike the SAML POST binding where signing is required to prevent intermediaries tampering with the requests.
+Another optional configuration is to sign SAML authentication requests. GitLab
+SAML Requests use the SAML redirect binding, so this isn't necessary (unlike the
+SAML POST binding, where signing is required to prevent intermediaries from
+tampering with the requests).
-In order to sign, you need to create a private key and public certificate pair for your GitLab instance to use for SAML. The settings related to signing can be set in the `security` section of the configuration.
+To sign, you need to create a private key and public certificate pair for your
+GitLab instance to use for SAML. The settings for signing can be set in the
+`security` section of the configuration.
For example:
@@ -648,13 +653,14 @@ If you only need a SAML provider for testing, a [quick start guide to start a Do
### 500 error after login
-If you see a "500 error" in GitLab when you are redirected back from the SAML sign in page,
-this likely indicates that GitLab could not get the email address for the SAML user.
+If you see a "500 error" in GitLab when you are redirected back from the SAML
+sign-in page, this likely indicates that GitLab couldn't get the email address
+for the SAML user.
-Make sure the IdP provides a claim containing the user's email address, using claim name
-`email` or `mail`.
+Ensure the IdP provides a claim containing the user's email address, using the
+claim name `email` or `mail`.
-### Redirect back to login screen with no evident error
+### Redirect back to the login screen with no evident error
If after signing in into your SAML server you are redirected back to the sign in page and
no error is displayed, check your `production.log` file. It will most likely contain the
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index cead8f7592a..ea63f16c72b 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -106,13 +106,17 @@ The following assumes you already have Vault installed and running.
vault login -method=oidc port=8250 role=demo
```
- Here is a short explanation of what this command does:
+ Here's a short explanation of what this command does:
- 1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
+ 1. In the **Write the OIDC Role Config** (step 4), we created a role called
+ `demo`. We set `role=demo` so Vault knows which configuration we'd like to
+ sign in with.
1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
- 1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
+ 1. To set the port that GitLab should redirect to, we set `port=8250` or
+ another port number that matches the port given to GitLab when listing
+ [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
- Once you run the command above, it will present a link in the terminal.
+ After running the command, it will present a link in the terminal.
Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md
index cfe950d7c96..66e11587e96 100644
--- a/doc/security/reset_user_password.md
+++ b/doc/security/reset_user_password.md
@@ -56,14 +56,15 @@ Don't forget to save the changes.
user.save!
```
-Exit the console and try to login with your new password.
+Exit the console, and then try to sign in with your new password.
NOTE: **Note:**
-Passwords can also be reset via the [Users API](../api/users.md#user-modification)
+You can also reset passwords by using the [Users API](../api/users.md#user-modification).
### Reset your root password
-The steps described above can also be used to reset the root password. But first, identify the root user, with an `id` of `1`. To do so, run the following command:
+The previously described steps can also be used to reset the root password. First,
+identify the root user, with an `id` of `1`. To do so, run the following command:
```shell
user = User.where(id: 1).first
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 995dea7809e..27cc2474b8a 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -8,22 +8,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Enforce Two-factor Authentication (2FA)
Two-factor Authentication (2FA) provides an additional level of security to your
-users' GitLab account. Once enabled, in addition to supplying their username and
-password to login, they'll be prompted for a code generated by an application on
-their phone.
+users' GitLab account. After being enabled, in addition to supplying their
+username and password to sign in, they'll be prompted for a code generated by an
+application on their phone.
You can read more about it here:
[Two-factor Authentication (2FA)](../user/profile/account/two_factor_authentication.md)
## Enforcing 2FA for all users
-Users on GitLab, can enable it without any admin's intervention. If you want to
-enforce everyone to set up 2FA, you can choose from two different ways:
+Users on GitLab can enable it without any administrator's intervention. If you
+want to enforce everyone to set up 2FA, you can choose from two different ways:
- Enforce on next login.
- Suggest on next login, but allow a grace period before enforcing.
-After the configured grace period has elapsed, users will be able to log in but
+After the configured grace period has elapsed, users will be able to sign in but
won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
To enable 2FA for all users:
@@ -32,15 +32,17 @@ To enable 2FA for all users:
(`/admin/application_settings/general`).
1. Expand the **Sign-in restrictions** section, where you can configure both.
-If you want 2FA enforcement to take effect on next login, change the grace
-period to `0`.
+If you want 2FA enforcement to take effect during the next sign-in attempt,
+change the grace period to `0`.
## Enforcing 2FA for all users in a group
If you want to enforce 2FA only for certain groups, you can:
-1. Enable it in the group's **Settings > General** page. Navigate to **Permissions, LFS, 2FA > Two-factor authentication**.
-You can then check the **Require all users in this group to setup Two-factor authentication** option.
+1. Enable it in the group's **Settings > General** page. Navigate to
+ **Permissions, LFS, 2FA > Two-factor authentication**. You can then select
+ the **Require all users in this group to setup Two-factor authentication**
+ option.
1. You can also specify a grace period in the **Time before enforced** option.
To change this setting, you need to be administrator or owner of the group.
diff --git a/doc/system_hooks/system_hooks.md b/doc/system_hooks/system_hooks.md
index 64d7f789850..9f42c96e31b 100644
--- a/doc/system_hooks/system_hooks.md
+++ b/doc/system_hooks/system_hooks.md
@@ -31,11 +31,18 @@ Your GitLab instance can perform HTTP POST requests on the following events:
- `user_update_for_group`
- `user_update_for_team`
-The triggers for most of these are self-explanatory, but `project_update` and `project_rename` deserve some clarification: `project_update` is fired any time an attribute of a project is changed (name, description, tags, etc.) *unless* the `path` attribute is also changed. In that case, a `project_rename` is triggered instead (so that, for instance, if all you care about is the repository URL, you can just listen for `project_rename`).
-
-`user_failed_login` is sent whenever a **blocked** user attempts to login and denied access.
-
-System hooks can be used, e.g. for logging or changing information in a LDAP server.
+The triggers for most of these are self-explanatory, but `project_update` and
+`project_rename` deserve some clarification: `project_update` is fired any time
+an attribute of a project is changed (including name, description, and tags)
+_unless_ the `path` attribute is also changed. In that case, a `project_rename`
+is triggered instead (so that, for instance, if all you care about is the
+repository URL, you can just listen for `project_rename`).
+
+`user_failed_login` is sent whenever a _blocked_ user attempts to sign in and is
+denied access.
+
+System hooks can be used, for example, for logging or changing information in an
+LDAP server.
NOTE: **Note:**
We follow the same structure and deprecations as [Webhooks](../user/project/integrations/webhooks.md)
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index eb01518ab51..21d495de5b7 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -23,7 +23,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
| [Account and limit](account_and_limit_settings.md) **(STARTER)** | Set projects and maximum size limits, session duration, user options, and check feature availability for namespace plan. |
| [Diff limits](../diff_limits.md) | Diff content limits. |
| [Sign-up restrictions](sign_up_restrictions.md) | Configure the way a user creates a new account. |
-| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign-in. Enable mandatory two-factor authentication. |
+| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign in. Enable mandatory two-factor authentication. |
| [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. |
| [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization |
| [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. |
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 36c4f2838f1..c6b9c574242 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -76,6 +76,7 @@ How you enable container scanning depends on your GitLab version:
that comes with your GitLab installation.
- GitLab versions earlier than 11.9: Copy and use the job from the
[`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml).
+- GitLab 13.6 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/263482) better support for [FIPS](https://csrc.nist.gov/publications/detail/fips/140/2/final) by upgrading the `CS_MAJOR_VERSION` from `2` to `3`.
To include the `Container-Scanning.gitlab-ci.yml` template (GitLab 11.9 and later), add the
following to your `.gitlab-ci.yml` file:
@@ -144,6 +145,26 @@ variables:
CLAIR_OUTPUT: High
```
+Version `3` of the `container_scanning` Docker image uses [`centos:centos8`](https://hub.docker.com/_/centos)
+as the new base. It also removes the use of the [start.sh](https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/merge_requests/77)
+script and instead executes the analyzer by default. Any customizations made to the
+`container_scanning` job's [`before_script`](../../../ci/yaml/README.md#before_script-and-after_script)
+and [`after_script`](../../../ci/yaml/README.md#before_script-and-after_script)
+blocks may not work with the new version. To roll back to the previous [`alpine:3.11.3`](https://hub.docker.com/_/alpine)-based
+Docker image, you can specify the major version through the [`CS_MAJOR_VERSION`](#available-variables)
+variable.
+
+This example [includes](../../../ci/yaml/README.md#include) the container scanning template and
+enables version `2` of the analyzer:
+
+```yaml
+include:
+ - template: Container-Scanning.gitlab-ci.yml
+
+variables:
+ CS_MAJOR_VERSION: '2'
+```
+
<!-- NOTE: The container scanning tool references the following heading in the code, so if you"
make a change to this heading, make sure to update the documentation URLs used in the"
container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar)" -->
@@ -164,6 +185,7 @@ scanning by using the following environment variables:
| `CLAIR_VULNERABILITIES_DB_URL` | `clair-vulnerabilities-db` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone container scanning tool](#running-the-standalone-container-scanning-tool) section. |
| `CI_APPLICATION_REPOSITORY` | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | Docker repository URL for the image to be scanned. |
| `CI_APPLICATION_TAG` | `$CI_COMMIT_SHA` | Docker repository tag for the image to be scanned. |
+| `CS_MAJOR_VERSION` | `3` | The major version of the Docker image tag. |
| `DOCKER_INSECURE` | `"false"` | Allow [Klar](https://github.com/optiopay/klar) to access secure Docker registries using HTTPS with bad (or self-signed) SSL certificates. |
| `DOCKER_PASSWORD` | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. |
| `DOCKER_USER` | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. |
diff --git a/doc/user/packages/nuget_repository/index.md b/doc/user/packages/nuget_repository/index.md
index 81829a36c0e..e95055ba02b 100644
--- a/doc/user/packages/nuget_repository/index.md
+++ b/doc/user/packages/nuget_repository/index.md
@@ -220,8 +220,6 @@ updated:
deploy:
stage: deploy
script:
- - dotnet restore -p:Configuration=Release
- - dotnet build -c Release
- dotnet pack -c Release
- dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text
- dotnet nuget push "bin/Release/*.nupkg" --source gitlab
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index ef0bdfc14c3..c0152ce7d88 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -8,12 +8,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Two-factor authentication
Two-factor authentication (2FA) provides an additional level of security to your
-GitLab account. Once enabled, in addition to supplying your username and
-password to login, you'll be prompted for a code generated by your one time password
-authenticator. For example, a password manager on one of your devices.
+GitLab account. After being enabled, in addition to supplying your username and
+password to sign in, you'll be prompted for a code generated by your one-time
+password authenticator (for example, a password manager on one of your devices).
-By enabling 2FA, the only way someone other than you can log into your account
-is to know your username and password *and* have access to your one time password secret.
+By enabling 2FA, the only way someone other than you can sign in to your account
+is to know your username and password _and_ have access to your one-time
+password secret.
## Overview
@@ -41,10 +42,10 @@ or a U2F / WebAuthn device.
To enable 2FA:
1. **In GitLab:**
- 1. Log in to your GitLab account.
+ 1. Sign in to your GitLab account.
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Go to **Account**.
- 1. Click **Enable Two-factor Authentication**.
+ 1. Select **Enable Two-factor Authentication**.
1. **On your device (usually your phone):**
1. Install a compatible application, like:
- [Authenticator](https://mattrubin.me/authenticator/): open source app for iOS devices.
@@ -59,11 +60,11 @@ To enable 2FA:
1. **In GitLab:**
1. Enter the six-digit pin number from the entry on your device into the **Pin
code** field.
- 1. Click **Submit**.
+ 1. Select **Submit**.
If the pin you entered was correct, you'll see a message indicating that
two-factor authentication has been enabled, and you'll be presented with a list
-of [recovery codes](#recovery-codes). Make sure you download them and keep them
+of [recovery codes](#recovery-codes). Be sure to download them and keep them
in a safe place.
### One-time password via FortiAuthenticator
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index aafc7a3b5b1..1ac528ca4ae 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -13,57 +13,61 @@ type: howto
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29280) from **Settings > CI / CD** in GitLab 12.10.1.
> - [Added package registry scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) in GitLab 13.0.
-Deploy tokens allow you to download (`git clone`) or push and pull packages and container registry images of a project without having a user and a password.
+Deploy tokens allow you to download (`git clone`) or push and pull packages and
+container registry images of a project without having a user and a password.
Deploy tokens can be managed by [maintainers only](../../permissions.md).
-If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys) instead.
+If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys)
+instead.
## Creating a Deploy Token
-You can create as many deploy tokens as you like from the settings of your project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
+You can create as many deploy tokens as you need from the settings of your
+project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
-1. Log in to your GitLab account.
+1. Sign in to your GitLab account.
1. Go to the project (or group) you want to create Deploy Tokens for.
1. Go to **Settings > Repository**.
1. Click on "Expand" on **Deploy Tokens** section.
1. Choose a name, expiry date (optional), and username (optional) for the token.
1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
-1. Click on **Create deploy token**.
-1. Save the deploy token somewhere safe. Once you leave or refresh
+1. Select **Create deploy token**.
+1. Save the deploy token somewhere safe. After you leave or refresh
the page, **you won't be able to access it again**.
![Personal access tokens page](img/deploy_tokens.png)
## Deploy token expiration
-Deploy tokens expire on the date you define, at midnight UTC.
+Deploy tokens expire at midnight UTC on the date you define.
## Revoking a deploy token
-At any time, you can revoke any deploy token by just clicking the
-respective **Revoke** button under the 'Active deploy tokens' area.
+At any time, you can revoke any deploy token by just clicking the respective
+**Revoke** button under the 'Active deploy tokens' area.
## Limiting scopes of a deploy token
-Deploy tokens can be created with different scopes that allow various
-actions that a given token can perform. The available scopes are depicted in
-the following table along with GitLab version it was introduced in.
+Deploy tokens can be created with different scopes that allow various actions
+that a given token can perform. The available scopes are depicted in the
+following table along with GitLab version it was introduced in:
-| Scope | Description | Introduced in GitLab Version |
-| ----- | ----------- | ------ |
-| `read_repository` | Allows read-access to the repository through `git clone` | 10.7 |
-| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
-| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
-| `read_package_registry` | Allows read access to the package registry. | 13.0 |
+| Scope | Description | Introduced in GitLab Version |
+|--------------------------|-------------|------------------------------|
+| `read_repository` | Allows read-access to the repository through `git clone` | 10.7 |
+| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
+| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
+| `read_package_registry` | Allows read access to the package registry. | 13.0 |
| `write_package_registry` | Allows write access to the package registry. | 13.0 |
## Deploy token custom username
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29639) in GitLab 12.1.
-The default username format is `gitlab+deploy-token-#{n}`. Some tools or platforms may not support this format,
-in such case you can specify custom username to be used when creating the deploy token.
+The default username format is `gitlab+deploy-token-#{n}`. Some tools or
+platforms may not support this format; in this case you can specify a custom
+username to be used when creating the deploy token.
## Usage
@@ -87,13 +91,13 @@ To read the container registry images, you'll need to:
1. Create a Deploy Token with `read_registry` as a scope.
1. Take note of your `username` and `token`.
-1. Log in to GitLab’s Container Registry using the deploy token:
+1. Sign in to GitLab’s Container Registry using the deploy token:
```shell
docker login -u <username> -p <deploy_token> registry.example.com
```
-Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
+Replace `<username>` and `<deploy_token>` with the proper values. You can now
pull images from your Container Registry.
### Push Container Registry images
@@ -104,13 +108,13 @@ To push the container registry images, you'll need to:
1. Create a Deploy Token with `write_registry` as a scope.
1. Take note of your `username` and `token`.
-1. Log in to GitLab’s Container Registry using the deploy token:
+1. Sign in to GitLab’s Container Registry using the deploy token:
```shell
docker login -u <username> -p <deploy_token> registry.example.com
```
-Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
+Replace `<username>` and `<deploy_token>` with the proper values. You can now
push images to your Container Registry.
### Read or pull packages
@@ -121,7 +125,8 @@ To pull packages in the GitLab package registry, you'll need to:
1. Create a Deploy Token with `read_package_registry` as a scope.
1. Take note of your `username` and `token`.
-1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
+1. For the [package type of your choice](../../packages/index.md), follow the
+ authentication instructions for deploy tokens.
### Push or upload packages
@@ -131,7 +136,8 @@ To upload packages in the GitLab package registry, you'll need to:
1. Create a Deploy Token with `write_package_registry` as a scope.
1. Take note of your `username` and `token`.
-1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
+1. For the [package type of your choice](../../packages/index.md), follow the
+ authentication instructions for deploy tokens.
### Group Deploy Token
@@ -158,10 +164,10 @@ apply consistently when cloning the repository of related projects.
There's a special case when it comes to Deploy Tokens. If a user creates one
named `gitlab-deploy-token`, the username and token of the Deploy Token will be
-automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER` and
-`CI_DEPLOY_PASSWORD`, respectively.
+automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
+and `CI_DEPLOY_PASSWORD`, respectively.
-After you create the token, you can login to the Container Registry using
+After you create the token, you can sign in to the Container Registry by using
those variables:
```shell
@@ -169,4 +175,7 @@ docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
```
NOTE: **Note:**
-The special handling for the `gitlab-deploy-token` deploy token is not currently implemented for group deploy tokens. For the deploy token to be available for CI/CD jobs, it must be created at the project level. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014) for details.
+The special handling for the `gitlab-deploy-token` deploy token is not currently
+implemented for group deploy tokens. For the deploy token to be available for
+CI/CD jobs, it must be created at the project level. For details, see
+[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014).
diff --git a/spec/factories/design_management/design_at_version.rb b/spec/factories/design_management/design_at_version.rb
index b73df71595c..3d85269ee27 100644
--- a/spec/factories/design_management/design_at_version.rb
+++ b/spec/factories/design_management/design_at_version.rb
@@ -9,13 +9,13 @@ FactoryBot.define do
version { nil }
transient do
- issue { design&.issue || version&.issue || create(:issue) }
+ issue { design&.issue || version&.issue || association(:issue) }
end
initialize_with do
attrs = attributes.dup
- attrs[:design] ||= create(:design, issue: issue)
- attrs[:version] ||= create(:design_version, issue: issue)
+ attrs[:design] ||= association(:design, issue: issue)
+ attrs[:version] ||= association(:design_version, issue: issue)
new(attrs)
end
diff --git a/spec/factories/design_management/designs.rb b/spec/factories/design_management/designs.rb
index 38d0545483c..c58763791cc 100644
--- a/spec/factories/design_management/designs.rb
+++ b/spec/factories/design_management/designs.rb
@@ -2,8 +2,8 @@
FactoryBot.define do
factory :design, class: 'DesignManagement::Design' do
- issue { create(:issue) }
- project { issue&.project || create(:project) }
+ issue { association(:issue) }
+ project { issue&.project || association(:project) }
sequence(:filename) { |n| "homescreen-#{n}.jpg" }
transient do
diff --git a/spec/factories/design_management/versions.rb b/spec/factories/design_management/versions.rb
index a5c0e7076e9..0233a3b567d 100644
--- a/spec/factories/design_management/versions.rb
+++ b/spec/factories/design_management/versions.rb
@@ -3,8 +3,8 @@
FactoryBot.define do
factory :design_version, class: 'DesignManagement::Version' do
sha
- issue { designs.first&.issue || create(:issue) }
- author { issue&.author || create(:user) }
+ issue { designs.first&.issue || association(:issue) }
+ author { issue&.author || association(:user) }
transient do
designs_count { 1 }
diff --git a/spec/frontend/pipelines/header_component_spec.js b/spec/frontend/pipelines/header_component_spec.js
index 2e10b0f068c..6b7371a934a 100644
--- a/spec/frontend/pipelines/header_component_spec.js
+++ b/spec/frontend/pipelines/header_component_spec.js
@@ -1,19 +1,19 @@
import { shallowMount } from '@vue/test-utils';
import { GlModal, GlLoadingIcon } from '@gitlab/ui';
-import MockAdapter from 'axios-mock-adapter';
import {
mockCancelledPipelineHeader,
mockFailedPipelineHeader,
mockRunningPipelineHeader,
mockSuccessfulPipelineHeader,
} from './mock_data';
-import axios from '~/lib/utils/axios_utils';
import HeaderComponent from '~/pipelines/components/header_component.vue';
+import deletePipelineMutation from '~/pipelines/graphql/mutations/delete_pipeline.mutation.graphql';
+import retryPipelineMutation from '~/pipelines/graphql/mutations/retry_pipeline.mutation.graphql';
+import cancelPipelineMutation from '~/pipelines/graphql/mutations/cancel_pipeline.mutation.graphql';
describe('Pipeline details header', () => {
let wrapper;
let glModalDirective;
- let mockAxios;
const findDeleteModal = () => wrapper.find(GlModal);
const findRetryButton = () => wrapper.find('[data-testid="retryPipeline"]');
@@ -25,9 +25,7 @@ describe('Pipeline details header', () => {
pipelineId: 14,
pipelineIid: 1,
paths: {
- retry: '/retry',
- cancel: '/cancel',
- delete: '/delete',
+ pipelinesPath: '/namespace/my-project/-/pipelines',
fullProject: '/namespace/my-project',
},
};
@@ -43,6 +41,7 @@ describe('Pipeline details header', () => {
startPolling: jest.fn(),
},
},
+ mutate: jest.fn(),
};
return shallowMount(HeaderComponent, {
@@ -65,16 +64,9 @@ describe('Pipeline details header', () => {
});
};
- beforeEach(() => {
- mockAxios = new MockAdapter(axios);
- mockAxios.onGet('*').replyOnce(200);
- });
-
afterEach(() => {
wrapper.destroy();
wrapper = null;
-
- mockAxios.restore();
});
describe('initial loading', () => {
@@ -111,13 +103,13 @@ describe('Pipeline details header', () => {
wrapper = createComponent(mockCancelledPipelineHeader);
});
- it('should call axios with the right path when retry button is clicked', async () => {
- jest.spyOn(axios, 'post');
+ it('should call retryPipeline Mutation with pipeline id', () => {
findRetryButton().vm.$emit('click');
- await wrapper.vm.$nextTick();
-
- expect(axios.post).toHaveBeenCalledWith(defaultProvideOptions.paths.retry);
+ expect(wrapper.vm.$apollo.mutate).toHaveBeenCalledWith({
+ mutation: retryPipelineMutation,
+ variables: { id: mockCancelledPipelineHeader.id },
+ });
});
});
@@ -126,13 +118,13 @@ describe('Pipeline details header', () => {
wrapper = createComponent(mockRunningPipelineHeader);
});
- it('should call axios with the right path when cancel button is clicked', async () => {
- jest.spyOn(axios, 'post');
+ it('should call cancelPipeline Mutation with pipeline id', () => {
findCancelButton().vm.$emit('click');
- await wrapper.vm.$nextTick();
-
- expect(axios.post).toHaveBeenCalledWith(defaultProvideOptions.paths.cancel);
+ expect(wrapper.vm.$apollo.mutate).toHaveBeenCalledWith({
+ mutation: cancelPipelineMutation,
+ variables: { id: mockRunningPipelineHeader.id },
+ });
});
});
@@ -141,24 +133,21 @@ describe('Pipeline details header', () => {
wrapper = createComponent(mockFailedPipelineHeader);
});
- it('displays delete modal when clicking on delete and does not call the delete action', async () => {
- jest.spyOn(axios, 'delete');
+ it('displays delete modal when clicking on delete and does not call the delete action', () => {
findDeleteButton().vm.$emit('click');
- await wrapper.vm.$nextTick();
-
expect(findDeleteModal().props('modalId')).toBe(wrapper.vm.$options.DELETE_MODAL_ID);
expect(glModalDirective).toHaveBeenCalledWith(wrapper.vm.$options.DELETE_MODAL_ID);
- expect(axios.delete).not.toHaveBeenCalled();
+ expect(wrapper.vm.$apollo.mutate).not.toHaveBeenCalled();
});
- it('should call delete path when modal is submitted', async () => {
- jest.spyOn(axios, 'delete');
+ it('should call deletePipeline Mutation with pipeline id when modal is submitted', () => {
findDeleteModal().vm.$emit('ok');
- await wrapper.vm.$nextTick();
-
- expect(axios.delete).toHaveBeenCalledWith(defaultProvideOptions.paths.delete);
+ expect(wrapper.vm.$apollo.mutate).toHaveBeenCalledWith({
+ mutation: deletePipelineMutation,
+ variables: { id: mockFailedPipelineHeader.id },
+ });
});
});
});
diff --git a/spec/graphql/resolvers/alert_management/integrations_resolver_spec.rb b/spec/graphql/resolvers/alert_management/integrations_resolver_spec.rb
index 126051783de..910da77ad48 100644
--- a/spec/graphql/resolvers/alert_management/integrations_resolver_spec.rb
+++ b/spec/graphql/resolvers/alert_management/integrations_resolver_spec.rb
@@ -14,6 +14,10 @@ RSpec.describe Resolvers::AlertManagement::IntegrationsResolver do
subject { sync(resolve_http_integrations) }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::AlertManagement::IntegrationType.connection_type)
+ end
+
context 'user does not have permission' do
it { is_expected.to be_empty }
end
diff --git a/spec/graphql/resolvers/base_resolver_spec.rb b/spec/graphql/resolvers/base_resolver_spec.rb
index 40dc2370052..e5b9fb57e42 100644
--- a/spec/graphql/resolvers/base_resolver_spec.rb
+++ b/spec/graphql/resolvers/base_resolver_spec.rb
@@ -7,10 +7,13 @@ RSpec.describe Resolvers::BaseResolver do
let(:resolver) do
Class.new(described_class) do
- def resolve(**args)
+ argument :test, ::GraphQL::INT_TYPE, required: false
+ type [::GraphQL::INT_TYPE], null: true
+
+ def resolve(test: 100)
process(object)
- [args, args]
+ [test, test]
end
def process(obj); end
@@ -19,17 +22,75 @@ RSpec.describe Resolvers::BaseResolver do
let(:last_resolver) do
Class.new(described_class) do
+ type [::GraphQL::INT_TYPE], null: true
+
def resolve(**args)
[1, 2]
end
end
end
+ describe '.singular_type' do
+ subject { resolver.singular_type }
+
+ context 'for a connection of scalars' do
+ let(:resolver) do
+ Class.new(described_class) do
+ type ::GraphQL::INT_TYPE.connection_type, null: true
+ end
+ end
+
+ it { is_expected.to eq(::GraphQL::INT_TYPE) }
+ end
+
+ context 'for a connection of objects' do
+ let(:object) do
+ Class.new(::Types::BaseObject) do
+ graphql_name 'Foo'
+ end
+ end
+
+ let(:resolver) do
+ conn = object.connection_type
+
+ Class.new(described_class) do
+ type conn, null: true
+ end
+ end
+
+ it { is_expected.to eq(object) }
+ end
+
+ context 'for a list type' do
+ let(:resolver) do
+ Class.new(described_class) do
+ type [::GraphQL::STRING_TYPE], null: true
+ end
+ end
+
+ it { is_expected.to eq(::GraphQL::STRING_TYPE) }
+ end
+
+ context 'for a scalar type' do
+ let(:resolver) do
+ Class.new(described_class) do
+ type ::GraphQL::BOOLEAN_TYPE, null: true
+ end
+ end
+
+ it { is_expected.to eq(::GraphQL::BOOLEAN_TYPE) }
+ end
+ end
+
describe '.single' do
it 'returns a subclass from the resolver' do
expect(resolver.single.superclass).to eq(resolver)
end
+ it 'has the correct (singular) type' do
+ expect(resolver.single.type).to eq(::GraphQL::INT_TYPE)
+ end
+
it 'returns the same subclass every time' do
expect(resolver.single.object_id).to eq(resolver.single.object_id)
end
@@ -37,15 +98,106 @@ RSpec.describe Resolvers::BaseResolver do
it 'returns a resolver that gives the first result from the original resolver' do
result = resolve(resolver.single, args: { test: 1 })
- expect(result).to eq(test: 1)
+ expect(result).to eq(1)
+ end
+ end
+
+ describe '.when_single' do
+ let(:resolver) do
+ Class.new(described_class) do
+ type [::GraphQL::INT_TYPE], null: true
+
+ when_single do
+ argument :foo, ::GraphQL::INT_TYPE, required: true
+ end
+
+ def resolve(foo: 1)
+ [foo * foo] # rubocop: disable Lint/BinaryOperatorWithIdenticalOperands
+ end
+ end
+ end
+
+ it 'does not apply the block to the resolver' do
+ expect(resolver.field_options).to include(
+ arguments: be_empty
+ )
+ result = resolve(resolver)
+
+ expect(result).to eq([1])
+ end
+
+ it 'applies the block to the single version of the resolver' do
+ expect(resolver.single.field_options).to include(
+ arguments: match('foo' => an_instance_of(::Types::BaseArgument))
+ )
+ result = resolve(resolver.single, args: { foo: 7 })
+
+ expect(result).to eq(49)
+ end
+
+ context 'multiple when_single blocks' do
+ let(:resolver) do
+ Class.new(described_class) do
+ type [::GraphQL::INT_TYPE], null: true
+
+ when_single do
+ argument :foo, ::GraphQL::INT_TYPE, required: true
+ end
+
+ when_single do
+ argument :bar, ::GraphQL::INT_TYPE, required: true
+ end
+
+ def resolve(foo: 1, bar: 2)
+ [foo * bar]
+ end
+ end
+ end
+
+ it 'applies both blocks to the single version of the resolver' do
+ expect(resolver.single.field_options).to include(
+ arguments: match('foo' => ::Types::BaseArgument, 'bar' => ::Types::BaseArgument)
+ )
+ result = resolve(resolver.single, args: { foo: 7, bar: 5 })
+
+ expect(result).to eq(35)
+ end
+ end
+
+ context 'inheritance' do
+ let(:subclass) do
+ Class.new(resolver) do
+ when_single do
+ argument :inc, ::GraphQL::INT_TYPE, required: true
+ end
+
+ def resolve(foo:, inc:)
+ super(foo: foo + inc)
+ end
+ end
+ end
+
+ it 'applies both blocks to the single version of the resolver' do
+ expect(resolver.single.field_options).to include(
+ arguments: match('foo' => ::Types::BaseArgument)
+ )
+ expect(subclass.single.field_options).to include(
+ arguments: match('foo' => ::Types::BaseArgument, 'inc' => ::Types::BaseArgument)
+ )
+ result = resolve(subclass.single, args: { foo: 7, inc: 1 })
+
+ expect(result).to eq(64)
+ end
end
end
context 'when the resolver returns early' do
let(:resolver) do
Class.new(described_class) do
+ type [::GraphQL::STRING_TYPE], null: true
+
def ready?(**args)
- [false, %w(early return)]
+ [false, %w[early return]]
end
def resolve(**args)
@@ -121,28 +273,4 @@ RSpec.describe Resolvers::BaseResolver do
end
end
end
-
- describe '#synchronized_object' do
- let(:object) { double(foo: :the_foo) }
-
- let(:resolver) do
- Class.new(described_class) do
- def resolve(**args)
- [synchronized_object.foo]
- end
- end
- end
-
- it 'handles raw objects' do
- expect(resolve(resolver, obj: object)).to contain_exactly(:the_foo)
- end
-
- it 'handles lazy objects' do
- delayed = BatchLoader::GraphQL.for(1).batch do |_, loader|
- loader.call(1, object)
- end
-
- expect(resolve(resolver, obj: delayed)).to contain_exactly(:the_foo)
- end
- end
end
diff --git a/spec/graphql/resolvers/design_management/design_resolver_spec.rb b/spec/graphql/resolvers/design_management/design_resolver_spec.rb
index d119b64a93e..e33eaedf167 100644
--- a/spec/graphql/resolvers/design_management/design_resolver_spec.rb
+++ b/spec/graphql/resolvers/design_management/design_resolver_spec.rb
@@ -6,6 +6,10 @@ RSpec.describe Resolvers::DesignManagement::DesignResolver do
include GraphqlHelpers
include DesignManagementTestHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(::Types::DesignManagement::DesignType)
+ end
+
before do
enable_design_management
end
diff --git a/spec/graphql/resolvers/design_management/designs_resolver_spec.rb b/spec/graphql/resolvers/design_management/designs_resolver_spec.rb
index cb56920563b..28e963c88a9 100644
--- a/spec/graphql/resolvers/design_management/designs_resolver_spec.rb
+++ b/spec/graphql/resolvers/design_management/designs_resolver_spec.rb
@@ -6,6 +6,10 @@ RSpec.describe Resolvers::DesignManagement::DesignsResolver do
include GraphqlHelpers
include DesignManagementTestHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(::Types::DesignManagement::DesignType.connection_type)
+ end
+
before do
enable_design_management
end
diff --git a/spec/graphql/resolvers/echo_resolver_spec.rb b/spec/graphql/resolvers/echo_resolver_spec.rb
index 7d7e8cdf387..4f48e5e0d7a 100644
--- a/spec/graphql/resolvers/echo_resolver_spec.rb
+++ b/spec/graphql/resolvers/echo_resolver_spec.rb
@@ -9,10 +9,7 @@ RSpec.describe Resolvers::EchoResolver do
let(:text) { 'Message test' }
specify do
- expect(described_class.field_options).to include(
- type: eq(::GraphQL::STRING_TYPE),
- null: be_falsey
- )
+ expect(described_class).to have_non_null_graphql_type(::GraphQL::STRING_TYPE)
end
describe '#resolve' do
diff --git a/spec/graphql/resolvers/error_tracking/sentry_detailed_error_resolver_spec.rb b/spec/graphql/resolvers/error_tracking/sentry_detailed_error_resolver_spec.rb
index 7e531910184..145aada019e 100644
--- a/spec/graphql/resolvers/error_tracking/sentry_detailed_error_resolver_spec.rb
+++ b/spec/graphql/resolvers/error_tracking/sentry_detailed_error_resolver_spec.rb
@@ -10,6 +10,10 @@ RSpec.describe Resolvers::ErrorTracking::SentryDetailedErrorResolver do
let(:issue_details_service) { spy('ErrorTracking::IssueDetailsService') }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::ErrorTracking::SentryDetailedErrorType)
+ end
+
before do
project.add_developer(current_user)
diff --git a/spec/graphql/resolvers/error_tracking/sentry_error_collection_resolver_spec.rb b/spec/graphql/resolvers/error_tracking/sentry_error_collection_resolver_spec.rb
index 02e0420be2a..20c2bdcd4e1 100644
--- a/spec/graphql/resolvers/error_tracking/sentry_error_collection_resolver_spec.rb
+++ b/spec/graphql/resolvers/error_tracking/sentry_error_collection_resolver_spec.rb
@@ -10,6 +10,10 @@ RSpec.describe Resolvers::ErrorTracking::SentryErrorCollectionResolver do
let(:list_issues_service) { spy('ErrorTracking::ListIssuesService') }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::ErrorTracking::SentryErrorCollectionType)
+ end
+
before do
project.add_developer(current_user)
diff --git a/spec/graphql/resolvers/error_tracking/sentry_errors_resolver_spec.rb b/spec/graphql/resolvers/error_tracking/sentry_errors_resolver_spec.rb
index 554873a6e21..edca11f40d7 100644
--- a/spec/graphql/resolvers/error_tracking/sentry_errors_resolver_spec.rb
+++ b/spec/graphql/resolvers/error_tracking/sentry_errors_resolver_spec.rb
@@ -14,6 +14,10 @@ RSpec.describe Resolvers::ErrorTracking::SentryErrorsResolver do
let(:issues) { nil }
let(:pagination) { nil }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::ErrorTracking::SentryErrorType.connection_type)
+ end
+
describe '#resolve' do
context 'insufficient user permission' do
let(:user) { create(:user) }
diff --git a/spec/graphql/resolvers/group_members_resolver_spec.rb b/spec/graphql/resolvers/group_members_resolver_spec.rb
index bbfea575492..bd0b4870062 100644
--- a/spec/graphql/resolvers/group_members_resolver_spec.rb
+++ b/spec/graphql/resolvers/group_members_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::GroupMembersResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::GroupMemberType.connection_type)
+ end
+
it_behaves_like 'querying members with a group' do
let_it_be(:resource_member) { create(:group_member, user: user_1, group: group_1) }
let_it_be(:resource) { group_1 }
diff --git a/spec/graphql/resolvers/issues_resolver_spec.rb b/spec/graphql/resolvers/issues_resolver_spec.rb
index 3a6507f906c..43cbd4d2bdd 100644
--- a/spec/graphql/resolvers/issues_resolver_spec.rb
+++ b/spec/graphql/resolvers/issues_resolver_spec.rb
@@ -20,6 +20,10 @@ RSpec.describe Resolvers::IssuesResolver do
let_it_be(:label1) { create(:label, project: project) }
let_it_be(:label2) { create(:label, project: project) }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::IssueType.connection_type)
+ end
+
context "with a project" do
before do
project.add_developer(current_user)
diff --git a/spec/graphql/resolvers/project_pipeline_resolver_spec.rb b/spec/graphql/resolvers/project_pipeline_resolver_spec.rb
index a6a86c49373..1950c2ca067 100644
--- a/spec/graphql/resolvers/project_pipeline_resolver_spec.rb
+++ b/spec/graphql/resolvers/project_pipeline_resolver_spec.rb
@@ -10,6 +10,10 @@ RSpec.describe Resolvers::ProjectPipelineResolver do
let_it_be(:other_pipeline) { create(:ci_pipeline) }
let(:current_user) { create(:user) }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(::Types::Ci::PipelineType)
+ end
+
def resolve_pipeline(project, args)
resolve(described_class, obj: project, args: args, ctx: { current_user: current_user })
end
diff --git a/spec/graphql/resolvers/projects/jira_imports_resolver_spec.rb b/spec/graphql/resolvers/projects/jira_imports_resolver_spec.rb
index 0775c1c31d1..ad59cb6b95e 100644
--- a/spec/graphql/resolvers/projects/jira_imports_resolver_spec.rb
+++ b/spec/graphql/resolvers/projects/jira_imports_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::Projects::JiraImportsResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::JiraImportType.connection_type)
+ end
+
describe '#resolve' do
let_it_be(:user) { create(:user) }
let_it_be(:project, reload: true) { create(:project, :public) }
diff --git a/spec/graphql/resolvers/projects/jira_projects_resolver_spec.rb b/spec/graphql/resolvers/projects/jira_projects_resolver_spec.rb
index 840aea8b8c4..c375345250d 100644
--- a/spec/graphql/resolvers/projects/jira_projects_resolver_spec.rb
+++ b/spec/graphql/resolvers/projects/jira_projects_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::Projects::JiraProjectsResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::Projects::Services::JiraProjectType.connection_type)
+ end
+
describe '#resolve' do
let_it_be(:user) { create(:user) }
let_it_be(:project) { create(:project) }
diff --git a/spec/graphql/resolvers/projects/services_resolver_spec.rb b/spec/graphql/resolvers/projects/services_resolver_spec.rb
index 8b6eff9e8b6..a1b631113b2 100644
--- a/spec/graphql/resolvers/projects/services_resolver_spec.rb
+++ b/spec/graphql/resolvers/projects/services_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::Projects::ServicesResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::Projects::ServiceType.connection_type)
+ end
+
describe '#resolve' do
let_it_be(:user) { create(:user) }
diff --git a/spec/graphql/resolvers/snippets/blobs_resolver_spec.rb b/spec/graphql/resolvers/snippets/blobs_resolver_spec.rb
index fdbd87c32be..16e69f662c0 100644
--- a/spec/graphql/resolvers/snippets/blobs_resolver_spec.rb
+++ b/spec/graphql/resolvers/snippets/blobs_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::Snippets::BlobsResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::Snippets::BlobType.connection_type)
+ end
+
describe '#resolve' do
let_it_be(:current_user) { create(:user) }
let_it_be(:snippet) { create(:personal_snippet, :private, :repository, author: current_user) }
diff --git a/spec/graphql/resolvers/todo_resolver_spec.rb b/spec/graphql/resolvers/todo_resolver_spec.rb
index 83e3140b676..c764f389c16 100644
--- a/spec/graphql/resolvers/todo_resolver_spec.rb
+++ b/spec/graphql/resolvers/todo_resolver_spec.rb
@@ -5,6 +5,10 @@ require 'spec_helper'
RSpec.describe Resolvers::TodoResolver do
include GraphqlHelpers
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::TodoType.connection_type)
+ end
+
describe '#resolve' do
let_it_be(:current_user) { create(:user) }
let_it_be(:author1) { create(:user) }
diff --git a/spec/graphql/resolvers/tree_resolver_spec.rb b/spec/graphql/resolvers/tree_resolver_spec.rb
index 7818c25fe47..9eafd272771 100644
--- a/spec/graphql/resolvers/tree_resolver_spec.rb
+++ b/spec/graphql/resolvers/tree_resolver_spec.rb
@@ -7,6 +7,10 @@ RSpec.describe Resolvers::TreeResolver do
let(:repository) { create(:project, :repository).repository }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::Tree::TreeType)
+ end
+
describe '#resolve' do
it 'resolves to a tree' do
result = resolve_repository({ ref: "master" })
diff --git a/spec/graphql/resolvers/users_resolver_spec.rb b/spec/graphql/resolvers/users_resolver_spec.rb
index a18a6dbfa80..1aa24055a89 100644
--- a/spec/graphql/resolvers/users_resolver_spec.rb
+++ b/spec/graphql/resolvers/users_resolver_spec.rb
@@ -8,6 +8,10 @@ RSpec.describe Resolvers::UsersResolver do
let_it_be(:user1) { create(:user, name: "SomePerson") }
let_it_be(:user2) { create(:user, username: "someone123784") }
+ specify do
+ expect(described_class).to have_nullable_graphql_type(Types::UserType.connection_type)
+ end
+
describe '#resolve' do
it 'raises an error when read_users_list is not authorized' do
expect(Ability).to receive(:allowed?).with(nil, :read_users_list).and_return(false)
diff --git a/spec/models/design_management/design_at_version_spec.rb b/spec/models/design_management/design_at_version_spec.rb
index 220de80a52a..a7cf6a9652b 100644
--- a/spec/models/design_management/design_at_version_spec.rb
+++ b/spec/models/design_management/design_at_version_spec.rb
@@ -185,7 +185,7 @@ RSpec.describe DesignManagement::DesignAtVersion do
end
describe 'validations' do
- subject(:design_at_version) { build(:design_at_version) }
+ subject(:design_at_version) { build_stubbed(:design_at_version) }
it { is_expected.to be_valid }
diff --git a/spec/models/design_management/version_spec.rb b/spec/models/design_management/version_spec.rb
index cd52f4129dc..e004ad024bc 100644
--- a/spec/models/design_management/version_spec.rb
+++ b/spec/models/design_management/version_spec.rb
@@ -31,7 +31,7 @@ RSpec.describe DesignManagement::Version do
it { is_expected.to validate_presence_of(:author) }
it { is_expected.to validate_presence_of(:sha) }
it { is_expected.to validate_presence_of(:designs) }
- it { is_expected.to validate_presence_of(:issue_id) }
+ it { is_expected.to validate_presence_of(:issue) }
it { is_expected.to validate_uniqueness_of(:sha).scoped_to(:issue_id).case_insensitive }
end
diff --git a/spec/support/matchers/graphql_matchers.rb b/spec/support/matchers/graphql_matchers.rb
index 7fa06e25405..8c4ba387a74 100644
--- a/spec/support/matchers/graphql_matchers.rb
+++ b/spec/support/matchers/graphql_matchers.rb
@@ -109,15 +109,82 @@ RSpec::Matchers.define :have_graphql_arguments do |*expected|
end
end
-RSpec::Matchers.define :have_graphql_type do |expected|
- match do |field|
- expect(field.type).to eq(expected)
+module GraphQLTypeHelpers
+ def message(object, expected, **opts)
+ non_null = expected.non_null? || (opts.key?(:null) && !opts[:null])
+
+ actual = object.type
+ actual_type = actual.unwrap.graphql_name
+ actual_type += '!' if actual.non_null?
+
+ expected_type = expected.unwrap.graphql_name
+ expected_type += '!' if non_null
+
+ "expected #{describe_object(object)} to have GraphQL type #{expected_type}, but got #{actual_type}"
+ end
+
+ def describe_object(object)
+ case object
+ when Types::BaseField
+ "#{describe_object(object.owner_type)}.#{object.graphql_name}"
+ when Types::BaseArgument
+ "#{describe_object(object.owner)}.#{object.graphql_name}"
+ when Class
+ object.try(:graphql_name) || object.name
+ else
+ object.to_s
+ end
+ end
+
+ def nullified(type, can_be_nil)
+ return type if can_be_nil.nil? # unknown!
+ return type if can_be_nil
+
+ type.to_non_null_type
+ end
+end
+
+RSpec::Matchers.define :have_graphql_type do |expected, opts = {}|
+ include GraphQLTypeHelpers
+
+ match do |object|
+ expect(object.type).to eq(nullified(expected, opts[:null]))
+ end
+
+ failure_message do |object|
+ message(object, expected, **opts)
+ end
+end
+
+RSpec::Matchers.define :have_nullable_graphql_type do |expected|
+ include GraphQLTypeHelpers
+
+ match do |object|
+ expect(object).to have_graphql_type(expected.unwrap, { null: true })
+ end
+
+ description do
+ "have nullable GraphQL type #{expected.graphql_name}"
+ end
+
+ failure_message do |object|
+ message(object, expected, null: true)
end
end
RSpec::Matchers.define :have_non_null_graphql_type do |expected|
- match do |field|
- expect(field.type.to_graphql).to eq(!expected.to_graphql)
+ include GraphQLTypeHelpers
+
+ match do |object|
+ expect(object).to have_graphql_type(expected, { null: false })
+ end
+
+ description do
+ "have non-null GraphQL type #{expected.graphql_name}"
+ end
+
+ failure_message do |object|
+ message(object, expected, null: false)
end
end