diff options
| -rw-r--r-- | .rubocop_manual_todo.yml | 1 | ||||
| -rw-r--r-- | config/feature_flags/development/redirect_to_latest_template_jobs_build.yml | 8 | ||||
| -rw-r--r-- | doc/.vale/gitlab/spelling-exceptions.txt | 2 | ||||
| -rw-r--r-- | doc/ci/lint.md | 7 | ||||
| -rw-r--r-- | doc/ci/pipelines/parent_child_pipelines.md | 6 | ||||
| -rw-r--r-- | doc/ci/yaml/index.md | 6 | ||||
| -rw-r--r-- | doc/integration/saml.md | 98 | ||||
| -rw-r--r-- | doc/subscriptions/bronze_starter.md | 2 | ||||
| -rw-r--r-- | lib/gitlab/ci/templates/Jobs/Build.latest.gitlab-ci.yml | 38 | ||||
| -rw-r--r-- | lib/gitlab/template/gitlab_ci_yml_template.rb | 1 | ||||
| -rw-r--r-- | spec/models/concerns/taggable_queries_spec.rb | 9 | ||||
| -rw-r--r-- | spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb | 53 |
12 files changed, 148 insertions, 83 deletions
diff --git a/.rubocop_manual_todo.yml b/.rubocop_manual_todo.yml index 76859cffde4..42b425bf7d7 100644 --- a/.rubocop_manual_todo.yml +++ b/.rubocop_manual_todo.yml @@ -866,7 +866,6 @@ RSpec/AnyInstanceOf: - 'spec/requests/api/ci/runner/runners_verify_post_spec.rb' - 'spec/requests/api/graphql/gitlab_schema_spec.rb' - 'spec/requests/api/graphql/project/error_tracking/sentry_detailed_error_request_spec.rb' - - 'spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb' - 'spec/requests/api/graphql_spec.rb' - 'spec/requests/api/helpers_spec.rb' - 'spec/requests/api/internal/base_spec.rb' diff --git a/config/feature_flags/development/redirect_to_latest_template_jobs_build.yml b/config/feature_flags/development/redirect_to_latest_template_jobs_build.yml new file mode 100644 index 00000000000..df03505afc5 --- /dev/null +++ b/config/feature_flags/development/redirect_to_latest_template_jobs_build.yml @@ -0,0 +1,8 @@ +--- +name: redirect_to_latest_template_jobs_build +introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67782 +rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/337990 +milestone: '14.2' +type: development +group: group::configure +default_enabled: false diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt index 012388f60c8..7b76f2e1e9c 100644 --- a/doc/.vale/gitlab/spelling-exceptions.txt +++ b/doc/.vale/gitlab/spelling-exceptions.txt @@ -162,6 +162,7 @@ dequarantine dequarantined dequarantining DevOps +Dhall disambiguates discoverability dismissable @@ -817,6 +818,7 @@ Worldline Xcode Xeon YouTrack +ytt Yubico Zeitwerk Zendesk diff --git a/doc/ci/lint.md b/doc/ci/lint.md index 4e3ac8b9e93..e01bd6b79ff 100644 --- a/doc/ci/lint.md +++ b/doc/ci/lint.md @@ -3,11 +3,8 @@ stage: Verify group: Pipeline Authoring info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -<!-- markdownlint-disable MD044 --> -<!-- vale gitlab.Spelling = NO --> -# Validate .gitlab-ci.yml syntax with the CI Lint tool -<!-- markdownlint-enable MD044 --> -<!-- vale gitlab.Spelling = YES --> + +# Validate `.gitlab-ci.yml` syntax with the CI Lint tool If you want to test the validity of your GitLab CI/CD configuration before committing the changes, you can use the CI Lint tool. This tool checks for syntax and logical diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md index b266a721d11..080227c6fc6 100644 --- a/doc/ci/pipelines/parent_child_pipelines.md +++ b/doc/ci/pipelines/parent_child_pipelines.md @@ -156,15 +156,11 @@ build a matrix of targets and architectures. <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For an overview, see [Create child pipelines using dynamically generated configurations](https://youtu.be/nMdfus2JWHM). -<!-- vale gitlab.Spelling = NO --> - We also have an example project using [Dynamic Child Pipelines with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet) which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime. You could use a similar process for other templating languages like -[Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/). - -<!-- vale gitlab.Spelling = NO --> +[Dhall](https://dhall-lang.org/) or [ytt](https://get-ytt.io/). The artifact path is parsed by GitLab, not the runner, so the path must match the syntax for the OS running GitLab. If GitLab is running on Linux but using a Windows diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index f04f50468f7..547a8c37e4c 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -5,11 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -<!-- markdownlint-disable MD044 --> -<!-- vale gitlab.Spelling = NO --> -# Keyword reference for the .gitlab-ci.yml file **(FREE)** -<!-- vale gitlab.Spelling = YES --> -<!-- markdownlint-enable MD044 --> +# Keyword reference for the `.gitlab-ci.yml` file **(FREE)** This document lists the configuration options for your GitLab `.gitlab-ci.yml` file. diff --git a/doc/integration/saml.md b/doc/integration/saml.md index ee3e2f574c7..b89772ba2ca 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -7,9 +7,11 @@ type: reference # SAML OmniAuth Provider **(FREE SELF)** -This page describes instance-wide SAML for self-managed GitLab instances. For SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md). +This page describes instance-wide SAML for self-managed GitLab instances. For +SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md). -You should also reference the [OmniAuth documentation](omniauth.md) for general settings that apply to all OmniAuth providers. +You should also reference the [OmniAuth documentation](omniauth.md) for general +settings that apply to all OmniAuth providers. ## Glossary of common terms @@ -19,7 +21,7 @@ You should also reference the [OmniAuth documentation](omniauth.md) for general | Service provider (SP) | GitLab can be configured as a SAML 2.0 SP. | | Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. | | Single Sign-On (SSO) | Name of authentication scheme. | -| Assertion consumer service URL | The callback on GitLab where users will be redirected after successfully authenticating with the identity provider. | +| Assertion consumer service URL | The callback on GitLab where users are redirected after successfully authenticating with the identity provider. | | Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". | | Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. | @@ -209,7 +211,7 @@ for a full list of supported assertions. ## SAML Groups -You can require users to be members of a certain group, or assign users [external](../user/permissions.md#external-users), admin or [auditor](../user/permissions.md#auditor-users) roles based on group membership. +You can require users to be members of a certain group, or assign users [external](../user/permissions.md#external-users), administrator or [auditor](../user/permissions.md#auditor-users) roles based on group membership. These groups are checked on each SAML login and user attributes updated as necessary. This feature **does not** allow you to automatically add users to GitLab [Groups](../user/group/index.md). @@ -221,13 +223,13 @@ and whether you've installed [GitLab Enterprise Edition (EE)](https://about.gitl |------------------------------|--------------------|--------------------------------------| | [Required](#required-groups) | **(FREE SELF)** | Yes | | [External](#external-groups) | **(FREE SELF)** | No | -| [Admin](#admin-groups) | **(FREE SELF)** | Yes | +| [Admin](#administrator-groups) | **(FREE SELF)** | Yes | | [Auditor](#auditor-groups) | **(PREMIUM SELF)** | Yes | ### Requirements -First you need to tell GitLab where to look for group information. For this you -need to make sure that your IdP server sends a specific `AttributeStatement` along +First tell GitLab where to look for group information. For this, you +must make sure that your IdP server sends a specific `AttributeStatement` along with the regular SAML response. Here is an example: ```xml @@ -242,17 +244,18 @@ with the regular SAML response. Here is an example: ``` The name of the attribute can be anything you like, but it must contain the groups -to which a user belongs. In order to tell GitLab where to find these groups, you need +to which a user belongs. To tell GitLab where to find these groups, you need to add a `groups_attribute:` element to your SAML settings. ### Required groups **(FREE SELF)** -Your IdP passes Group Information to the SP (GitLab) in the SAML Response. You need to configure GitLab to identify: +Your IdP passes Group information to the SP (GitLab) in the SAML Response. +To use this response, configure GitLab to identify: - Where to look for the groups in the SAML response via the `groups_attribute` setting - Which group membership is requisite to sign in via the `required_groups` setting -When `required_groups` is not set or it is empty, anyone with proper authentication +When `required_groups` is empty or not set, anyone with proper authentication is able to use the service. Example: @@ -273,7 +276,9 @@ Example: ### External groups **(FREE SELF)** -SAML login supports automatic identification on whether a user should be considered an [external user](../user/permissions.md#external-users). This is based on the user's group membership in the SAML identity provider. +SAML login supports the automatic identification of a user as an +[external user](../user/permissions.md#external-users). This is based on the user's group +membership in the SAML identity provider. ```yaml { name: 'saml', @@ -289,11 +294,13 @@ SAML login supports automatic identification on whether a user should be conside } } ``` -### Admin groups **(FREE SELF)** +### Administrator groups **(FREE SELF)** -The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell -GitLab where to look for the groups in the SAML response, and which group(s) should be -considered admin users. +The requirements are the same as the previous settings: + +- The IdP must pass Group information to GitLab. +- GitLab must know where to look for the groups in the SAML response, as well as + which group(s) grant the user an administrator role. ```yaml { name: 'saml', @@ -313,9 +320,11 @@ considered admin users. > Introduced in GitLab 11.4. -The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell -GitLab where to look for the groups in the SAML response, and which group(s) should be -considered [auditor users](../user/permissions.md#auditor-users). +The requirements are the same as the previous settings: + +- The IdP must pass Group information to GitLab. +- GitLab should know where to look for the groups in the SAML response, as well as which + group(s) entail that a given user is an [auditor user](../user/permissions.md#auditor-users). ```yaml { name: 'saml', @@ -333,8 +342,8 @@ considered [auditor users](../user/permissions.md#auditor-users). ## Bypass two factor authentication -If you want some SAML authentication methods to count as 2FA on a per session basis, you can register them in the -`upstream_two_factor_authn_contexts` list. +If you want some SAML authentication methods to count as 2FA on a per session +basis, you can register them in the `upstream_two_factor_authn_contexts` list. In addition to the changes in GitLab, make sure that your IdP is returning the `AuthnContext`. For example: @@ -411,7 +420,7 @@ In addition to the changes in GitLab, make sure that your IdP is returning the ### `auto_sign_in_with_provider` You can add this setting to your GitLab configuration to automatically redirect you -to your SAML server for authentication, thus removing the need to click a button +to your SAML server for authentication. This removes the requirement to click a button before actually signing in. For Omnibus package: @@ -429,7 +438,7 @@ omniauth: Keep in mind that every sign in attempt redirects to the SAML server; you cannot sign in using local credentials. Ensure at least one of the -SAML users has admin permissions. +SAML users has an administrator role. You may also bypass the auto sign-in feature by browsing to `https://gitlab.example.com/users/sign_in?auto_sign_in=false`. @@ -464,9 +473,14 @@ args: { } ``` -#### Setting a username +#### Set a username + +By default, the email in the SAML response is used to automatically generate the +user's GitLab username. If you'd like to set another attribute as the username, +assign it to the `nickname` OmniAuth `info` hash attribute. -By default, the email in the SAML response is used to automatically generate the user's GitLab username. If you'd like to set another attribute as the username, assign it to the `nickname` OmniAuth `info` hash attribute. For example, if you wanted to set the `username` attribute in your SAML Response to the username in GitLab, use the following setting: +For example, if you want to set the `username` attribute in your SAML Response to the username +in GitLab, use the following setting: ```yaml args: { @@ -482,7 +496,7 @@ args: { ### `allowed_clock_drift` The clock of the Identity Provider may drift slightly ahead of your system clocks. -To allow for a small amount of clock drift you can use `allowed_clock_drift` within +To allow for a small amount of clock drift, you can use `allowed_clock_drift` in your settings. Its value must be given in a number (and/or fraction) of seconds. The value given is added to the current time at which the response is validated. @@ -572,7 +586,8 @@ This may be the case, for example, if you terminate TLS encryption early at a lo balancer and include sensitive details in assertions that you do not want appearing in logs. Most organizations should not need additional encryption at this layer. -The SAML integration supports EncryptedAssertion. You need to define the private key and the public certificate of your GitLab instance in the SAML settings: +The SAML integration supports EncryptedAssertion. You should define the private +key and the public certificate of your GitLab instance in the SAML settings: ```yaml args: { @@ -602,7 +617,7 @@ 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). -To sign, you need to create a private key and public certificate pair for your +To sign, 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. @@ -653,7 +668,7 @@ The [Generated passwords for users created through integrated authentication](.. For information on the GitLab.com implementation, please see the [SAML SSO for GitLab.com groups page](../user/group/saml_sso). -Group SAML SSO helps if you need to allow access via multiple SAML identity providers, but as a multi-tenant solution is less suited to cases where you administer your own GitLab instance. +Group SAML SSO helps if you have to allow access via multiple SAML identity providers, but as a multi-tenant solution is less suited to cases where you administer your own GitLab instance. To proceed with configuring Group SAML SSO instead, enable the `group_saml` OmniAuth provider. This can be done from: @@ -668,7 +683,7 @@ Group SAML on a self-managed instance is limited when compared to the recommende - [LDAP compatibility](../administration/auth/ldap/index.md). - [LDAP Group Sync](../user/group/index.md#manage-group-memberships-via-ldap). - [Required groups](#required-groups). -- [Admin groups](#admin-groups). +- [Administrator groups](#administrator-groups). - [Auditor groups](#auditor-groups). ### Omnibus installations @@ -750,7 +765,7 @@ Make sure you have access to a Google Workspace [Super Admin](https://support.go | First name | `first_name` | Required value to communicate with GitLab. | | Last name | `last_name` | Required value to communicate with GitLab. | -You also need to setup the following SAML attribute mappings: +You also must setup the following SAML attribute mappings: | Google Directory attributes | App attributes | |-----------------------------------|----------------| @@ -767,8 +782,9 @@ When configuring the Google Workspace SAML app, be sure to record the following | SSO URL | Depends | Google Identity Provider details. Set to the GitLab `idp_sso_target_url` setting. | | Certificate | Downloadable | Run `openssl x509 -in <your_certificate.crt> -noout -fingerprint` to generate the SHA1 fingerprint that can be used in the `idp_cert_fingerprint` setting. | -While the Google Workspace Admin provides IdP metadata, Entity ID and SHA-256 fingerprint, -GitLab does not need that information to connect to the Google Workspace SAML app. +While the Google Workspace Admin provides IdP metadata, Entity ID, and SHA-256 +fingerprint, they are not required. GitLab does not need that information to +connect to the Google Workspace SAML app. ## Troubleshooting @@ -778,9 +794,10 @@ You can find the base64-encoded SAML Response in the [`production_json.log`](../ ### GitLab+SAML Testing Environments -If you need to troubleshoot, [a complete GitLab+SAML testing environment using Docker compose](https://gitlab.com/gitlab-com/support/toolbox/replication/tree/master/compose_files) is available. +To troubleshoot, [a complete GitLab+SAML testing environment using Docker compose](https://gitlab.com/gitlab-com/support/toolbox/replication/tree/master/compose_files) +is available. -If you only need a SAML provider for testing, a [quick start guide to start a Docker container](../administration/troubleshooting/test_environments.md#saml) with a plug and play SAML 2.0 Identity Provider (IdP) is available. +If you only require a SAML provider for testing, a [quick start guide to start a Docker container](../administration/troubleshooting/test_environments.md#saml) with a plug and play SAML 2.0 Identity Provider (IdP) is available. ### 500 error after login @@ -794,8 +811,8 @@ claim name `email` or `mail`. ### 422 error after login If you see a "422 error" in GitLab when you are redirected from the SAML -sign-in page, you might have an incorrectly configured assertion consumer -service (ACS) URL on the identity provider. +sign-in page, you might have an incorrectly configured Assertion Consumer +Service (ACS) URL on the identity provider. Make sure the ACS URL points to `https://gitlab.example.com/users/auth/saml/callback`, where `gitlab.example.com` is the URL of your GitLab instance. @@ -845,14 +862,17 @@ is not providing this information, all SAML requests fail. Make sure this information is provided. -Another issue that can result in this error is when the correct information is being sent by the IdP, but the attributes don't match the names in the OmniAuth `info` hash. In this case, you need to set `attribute_statements` in the SAML configuration to [map the attribute names in your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements). +Another issue that can result in this error is when the correct information is being sent by +the IdP, but the attributes don't match the names in the OmniAuth `info` hash. In this case, +you must set `attribute_statements` in the SAML configuration to [map the attribute names in +your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements). ### Key validation error, Digest mismatch or Fingerprint mismatch These errors all come from a similar place, the SAML certificate. SAML requests -need to be validated using a fingerprint, a certificate or a validator. +must be validated using either a fingerprint, a certificate, or a validator. -For this you need to take the following into account: +For this requirement, be sure to take the following into account: - If a fingerprint is used, it must be the SHA1 fingerprint - If no certificate is provided in the settings, a fingerprint or fingerprint diff --git a/doc/subscriptions/bronze_starter.md b/doc/subscriptions/bronze_starter.md index 961a6bf5ec4..0d3f9351c95 100644 --- a/doc/subscriptions/bronze_starter.md +++ b/doc/subscriptions/bronze_starter.md @@ -102,7 +102,7 @@ the tiers are no longer mentioned in GitLab documentation: - [Shared runners pipeline minutes quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota) - [Push rules](../push_rules/push_rules.md) - SAML for self-managed GitLab instance: - - [Administrator groups](../integration/saml.md#admin-groups) + - [Administrator groups](../integration/saml.md#administrator-groups) - [Auditor groups](../integration/saml.md#auditor-groups) - [External groups](../integration/saml.md#external-groups) - [Required groups](../integration/saml.md#required-groups) diff --git a/lib/gitlab/ci/templates/Jobs/Build.latest.gitlab-ci.yml b/lib/gitlab/ci/templates/Jobs/Build.latest.gitlab-ci.yml new file mode 100644 index 00000000000..cbbd3320d2f --- /dev/null +++ b/lib/gitlab/ci/templates/Jobs/Build.latest.gitlab-ci.yml @@ -0,0 +1,38 @@ +# WARNING: This latest template is for internal FEATURE-FLAG TESTING ONLY. +# It is not meant to be used with `include:`. +# This template is scheduled for removal when testing is complete: https://gitlab.com/gitlab-org/gitlab/-/issues/337987 + +build: + stage: build + image: 'registry.gitlab.com/gitlab-org/cluster-integration/auto-build-image:v1.3.1' + variables: + DOCKER_TLS_CERTDIR: '' + services: + - name: 'docker:20.10.6-dind' + command: ['--tls=false', '--host=tcp://0.0.0.0:2375'] + script: + - | + if [[ -z "$CI_COMMIT_TAG" ]]; then + export CI_APPLICATION_REPOSITORY=${CI_APPLICATION_REPOSITORY:-$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG} + export CI_APPLICATION_TAG=${CI_APPLICATION_TAG:-$CI_COMMIT_SHA} + else + export CI_APPLICATION_REPOSITORY=${CI_APPLICATION_REPOSITORY:-$CI_REGISTRY_IMAGE} + export CI_APPLICATION_TAG=${CI_APPLICATION_TAG:-$CI_COMMIT_TAG} + fi + - /build/build.sh + rules: + - if: '$BUILD_DISABLED' + when: never + - if: '$AUTO_DEVOPS_PLATFORM_TARGET == "EC2"' + when: never + - if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH' + +build_artifact: + stage: build + script: + - printf "To build your project, please create a build_artifact job into your .gitlab-ci.yml file.\nMore information at https://docs.gitlab.com/ee/ci/cloud_deployment\n" + - exit 1 + rules: + - if: '$BUILD_DISABLED' + when: never + - if: '$AUTO_DEVOPS_PLATFORM_TARGET == "EC2"' diff --git a/lib/gitlab/template/gitlab_ci_yml_template.rb b/lib/gitlab/template/gitlab_ci_yml_template.rb index da925f0f83a..263483ba54b 100644 --- a/lib/gitlab/template/gitlab_ci_yml_template.rb +++ b/lib/gitlab/template/gitlab_ci_yml_template.rb @@ -7,6 +7,7 @@ module Gitlab TEMPLATES_WITH_LATEST_VERSION = { 'Jobs/Browser-Performance-Testing' => true, + 'Jobs/Build' => true, 'Security/API-Fuzzing' => true, 'Security/DAST' => true, 'Terraform' => true diff --git a/spec/models/concerns/taggable_queries_spec.rb b/spec/models/concerns/taggable_queries_spec.rb new file mode 100644 index 00000000000..0d248c4636e --- /dev/null +++ b/spec/models/concerns/taggable_queries_spec.rb @@ -0,0 +1,9 @@ +# frozen_string_literal: true + +require 'spec_helper' + +RSpec.describe TaggableQueries do + it 'keeps MAX_TAGS_IDS in sync with TAGS_LIMIT' do + expect(described_class::MAX_TAGS_IDS).to eq(Gitlab::Ci::Config::Entry::Tags::TAGS_LIMIT) + end +end diff --git a/spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb b/spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb index 80376f56ee8..a540386a9de 100644 --- a/spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb +++ b/spec/requests/api/graphql/project/error_tracking/sentry_errors_request_spec.rb @@ -3,6 +3,7 @@ require 'spec_helper' RSpec.describe 'sentry errors requests' do include GraphqlHelpers + let_it_be(:project) { create(:project, :repository) } let_it_be(:project_setting) { create(:project_error_tracking_setting, project: project) } let_it_be(:current_user) { project.owner } @@ -30,7 +31,7 @@ RSpec.describe 'sentry errors requests' do let(:error_data) { graphql_data.dig('project', 'sentryErrors', 'detailedError') } - it 'returns a successful response', :aggregate_failures, :quarantine do + it 'returns a successful response', :aggregate_failures do post_graphql(query, current_user: current_user) expect(response).to have_gitlab_http_status(:success) @@ -48,11 +49,9 @@ RSpec.describe 'sentry errors requests' do end end - context 'reactive cache returns data' do + context 'when reactive cache returns data' do before do - allow_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:issue_details) - .and_return(issue: sentry_detailed_error) + stub_setting_for(:issue_details, issue: sentry_detailed_error) post_graphql(query, current_user: current_user) end @@ -72,7 +71,7 @@ RSpec.describe 'sentry errors requests' do end end - context 'user does not have permission' do + context 'when user does not have permission' do let(:current_user) { create(:user) } it 'is expected to return an empty error' do @@ -81,11 +80,9 @@ RSpec.describe 'sentry errors requests' do end end - context 'sentry api returns an error' do + context 'when sentry api returns an error' do before do - expect_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:issue_details) - .and_return(error: 'error message') + stub_setting_for(:issue_details, error: 'error message') post_graphql(query, current_user: current_user) end @@ -140,11 +137,11 @@ RSpec.describe 'sentry errors requests' do end end - context 'reactive cache returns data' do + context 'when reactive cache returns data' do before do - expect_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:list_sentry_issues) - .and_return(issues: [sentry_error], pagination: pagination) + stub_setting_for(:list_sentry_issues, + issues: [sentry_error], + pagination: pagination) post_graphql(query, current_user: current_user) end @@ -177,11 +174,9 @@ RSpec.describe 'sentry errors requests' do end end - context 'sentry api itself errors out' do + context 'when sentry api itself errors out' do before do - expect_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:list_sentry_issues) - .and_return(error: 'error message') + stub_setting_for(:list_sentry_issues, error: 'error message') post_graphql(query, current_user: current_user) end @@ -223,18 +218,16 @@ RSpec.describe 'sentry errors requests' do end end - context 'reactive cache returns data' do + context 'when reactive cache returns data' do before do - allow_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:issue_latest_event) - .and_return(latest_event: sentry_stack_trace) + stub_setting_for(:issue_latest_event, latest_event: sentry_stack_trace) post_graphql(query, current_user: current_user) end it_behaves_like 'setting stack trace error' - context 'user does not have permission' do + context 'when user does not have permission' do let(:current_user) { create(:user) } it 'is expected to return an empty error' do @@ -243,11 +236,9 @@ RSpec.describe 'sentry errors requests' do end end - context 'sentry api returns an error' do + context 'when sentry api returns an error' do before do - expect_any_instance_of(ErrorTracking::ProjectErrorTrackingSetting) - .to receive(:issue_latest_event) - .and_return(error: 'error message') + stub_setting_for(:issue_latest_event, error: 'error message') post_graphql(query, current_user: current_user) end @@ -257,4 +248,12 @@ RSpec.describe 'sentry errors requests' do end end end + + private + + def stub_setting_for(method, **return_value) + allow_next_found_instance_of(ErrorTracking::ProjectErrorTrackingSetting) do |setting| + allow(setting).to receive(method).and_return(**return_value) + end + end end |