Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
d8995bd33f
commit
a8b811acdf
|
|
@ -113,6 +113,10 @@ module AuthHelper
|
|||
end
|
||||
end
|
||||
|
||||
def experiment_enabled_button_based_providers
|
||||
enabled_button_based_providers & %w(google_oauth2 github).freeze
|
||||
end
|
||||
|
||||
def button_based_providers_enabled?
|
||||
enabled_button_based_providers.any?
|
||||
end
|
||||
|
|
|
|||
|
|
@ -40,13 +40,12 @@ module Issuable
|
|||
csv_data = @csv_io.open(&:read).force_encoding(Encoding::UTF_8)
|
||||
validate_headers_presence!(csv_data.lines.first)
|
||||
|
||||
csv_parsing_params = {
|
||||
CSV.new(
|
||||
csv_data,
|
||||
col_sep: detect_col_sep(csv_data.lines.first),
|
||||
headers: true,
|
||||
header_converters: :symbol
|
||||
}
|
||||
|
||||
CSV.new(csv_data, csv_parsing_params).each.with_index(2)
|
||||
).each.with_index(2)
|
||||
end
|
||||
|
||||
def validate_headers_presence!(headers)
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ module Notes
|
|||
track_event(note, current_user)
|
||||
|
||||
if Feature.enabled?(:notes_create_service_tracking, project)
|
||||
Gitlab::Tracking.event('Notes::CreateService', 'execute', tracking_data_for(note))
|
||||
Gitlab::Tracking.event('Notes::CreateService', 'execute', **tracking_data_for(note))
|
||||
end
|
||||
|
||||
if note.for_merge_request? && note.diff_note? && note.start_of_discussion?
|
||||
|
|
|
|||
|
|
@ -6,16 +6,18 @@ class UploadService
|
|||
end
|
||||
|
||||
def execute
|
||||
return unless @file && @file.size <= max_attachment_size
|
||||
return unless file && file.size <= max_attachment_size
|
||||
|
||||
uploader = @uploader_class.new(@model, nil, @uploader_context)
|
||||
uploader.store!(@file)
|
||||
uploader = uploader_class.new(model, nil, **uploader_context)
|
||||
uploader.store!(file)
|
||||
|
||||
uploader
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
attr_reader :model, :file, :uploader_class, :uploader_context
|
||||
|
||||
def max_attachment_size
|
||||
Gitlab::CurrentSettings.max_attachment_size.megabytes.to_i
|
||||
end
|
||||
|
|
|
|||
|
|
@ -1,7 +1,12 @@
|
|||
- max_first_name_length = max_last_name_length = 127
|
||||
- max_username_length = 255
|
||||
- min_username_length = 2
|
||||
- omniauth_providers_placement ||= :bottom
|
||||
|
||||
.gl-mb-3.gl-p-4.gl-border-gray-100.gl-border-1.gl-border-solid.gl-rounded-base
|
||||
- if show_omniauth_providers && omniauth_providers_placement == :top
|
||||
= render 'devise/shared/signup_omniauth_providers_top'
|
||||
|
||||
= form_for(resource, as: "new_#{resource_name}", url: url, html: { class: 'new_user gl-show-field-errors', 'aria-live' => 'assertive' }) do |f|
|
||||
.devise-errors
|
||||
= render 'devise/shared/error_messages', resource: resource
|
||||
|
|
@ -33,5 +38,5 @@
|
|||
.submit-container
|
||||
= f.submit button_text, class: 'btn gl-button btn-success', data: { qa_selector: 'new_user_register_button' }
|
||||
= render 'devise/shared/terms_of_service_notice'
|
||||
- if show_omniauth_providers
|
||||
- if show_omniauth_providers && omniauth_providers_placement == :bottom
|
||||
= render 'devise/shared/signup_omniauth_providers'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
%label.label-bold.d-block
|
||||
= _("Create an account using:")
|
||||
.d-flex.justify-content-between.flex-wrap
|
||||
- providers.each do |provider|
|
||||
= link_to omniauth_authorize_path(:user, provider), method: :post, class: "btn gl-button gl-display-flex gl-align-items-center gl-text-left gl-mb-2 gl-p-2 omniauth-btn oauth-login #{qa_class_for_provider(provider)}", id: "oauth-login-#{provider}" do
|
||||
- if provider_has_icon?(provider)
|
||||
= provider_image_tag(provider)
|
||||
%span.ml-2
|
||||
= label_for_provider(provider)
|
||||
|
|
@ -1,13 +1,3 @@
|
|||
.omniauth-divider.d-flex.align-items-center.text-center
|
||||
= _("or")
|
||||
%label.label-bold.d-block
|
||||
= _("Create an account using:")
|
||||
- providers = enabled_button_based_providers
|
||||
.d-flex.justify-content-between.flex-wrap
|
||||
- providers.each do |provider|
|
||||
- has_icon = provider_has_icon?(provider)
|
||||
= link_to omniauth_authorize_path(:user, provider), method: :post, class: "gl-button btn d-flex align-items-center omniauth-btn text-left oauth-login mb-2 p-2 #{qa_class_for_provider(provider)}", id: "oauth-login-#{provider}" do
|
||||
- if has_icon
|
||||
= provider_image_tag(provider)
|
||||
%span.ml-2
|
||||
= label_for_provider(provider)
|
||||
= render 'devise/shared/signup_omniauth_provider_list', providers: enabled_button_based_providers
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
= render 'devise/shared/signup_omniauth_provider_list', providers: experiment_enabled_button_based_providers
|
||||
.omniauth-divider.d-flex.align-items-center.text-center
|
||||
= _("or")
|
||||
|
|
@ -26,7 +26,7 @@
|
|||
- if issue.service_desk_reply_to
|
||||
#{issue.service_desk_reply_to} via
|
||||
#{link_to_member(@project, issue.author, avatar: false)}
|
||||
= render_if_exists 'shared/issuable/gitlab_team_member_badge', {author: issue.author}
|
||||
= render_if_exists 'shared/issuable/gitlab_team_member_badge', author: issue.author
|
||||
- if issue.milestone
|
||||
%span.issuable-milestone.d-none.d-sm-inline-block
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
·
|
||||
opened #{time_ago_with_tooltip(merge_request.created_at, placement: 'bottom')}
|
||||
by #{link_to_member(@project, merge_request.author, avatar: false)}
|
||||
= render_if_exists 'shared/issuable/gitlab_team_member_badge', {author: merge_request.author}
|
||||
= render_if_exists 'shared/issuable/gitlab_team_member_badge', author: merge_request.author
|
||||
- if merge_request.milestone
|
||||
%span.issuable-milestone.d-none.d-sm-inline-block
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@
|
|||
= f.hidden_field 'milestone_id', value: milestone[:id], id: nil
|
||||
= dropdown_tag('Milestone', options: { title: _('Assign milestone'), toggle_class: 'js-milestone-select js-extra-options', filter: true, dropdown_class: 'dropdown-menu-selectable', placeholder: _('Search milestones'), data: { show_no: true, field_name: "#{issuable_type}[milestone_id]", project_id: issuable_sidebar[:project_id], issuable_id: issuable_sidebar[:id], ability_name: issuable_type, issue_update: issuable_sidebar[:issuable_json_path], use_id: true, default_no: true, selected: milestone[:title], null_default: true, display: 'static' }})
|
||||
- if @project.group.present?
|
||||
= render_if_exists 'shared/issuable/iteration_select', { can_edit: can_edit_issuable, group_path: @project.group.full_path, project_path: issuable_sidebar[:project_full_path], issue_iid: issuable_sidebar[:iid], issuable_type: issuable_type }
|
||||
= render_if_exists 'shared/issuable/iteration_select', can_edit: can_edit_issuable, group_path: @project.group.full_path, project_path: issuable_sidebar[:project_full_path], issue_iid: issuable_sidebar[:iid], issuable_type: issuable_type
|
||||
|
||||
- if issuable_sidebar[:supports_time_tracking]
|
||||
#issuable-time-tracker.block
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ module WorkerContext
|
|||
|
||||
class_methods do
|
||||
def worker_context(attributes)
|
||||
@worker_context = Gitlab::ApplicationContext.new(attributes)
|
||||
@worker_context = Gitlab::ApplicationContext.new(**attributes)
|
||||
end
|
||||
|
||||
def get_worker_context
|
||||
|
|
@ -60,6 +60,6 @@ module WorkerContext
|
|||
end
|
||||
|
||||
def with_context(context, &block)
|
||||
Gitlab::ApplicationContext.new(context).use { yield(**context) }
|
||||
Gitlab::ApplicationContext.new(**context).use { yield(**context) }
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ in the application settings.
|
|||
When a user signs in to GitLab with LDAP for the first time, and their LDAP
|
||||
email address is the primary email address of an existing GitLab user, then
|
||||
the LDAP DN is associated with the existing user. If the LDAP email
|
||||
attribute is not found in GitLab's database, a new user is created.
|
||||
attribute is not found in the GitLab user database, a new user is created.
|
||||
|
||||
In other words, if an existing GitLab user wants to enable LDAP sign-in for
|
||||
themselves, they should check that their GitLab email address matches their
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ flags for a [number of reasons](../development/feature_flags/process.md#when-to-
|
|||
- To test the feature.
|
||||
- To get feedback from users and customers while in an early stage of the development of the feature.
|
||||
- To evaluate users adoption.
|
||||
- To evaluate how it impacts GitLab's performance.
|
||||
- To evaluate how it impacts the performance of GitLab.
|
||||
- To build it in smaller pieces throughout releases.
|
||||
|
||||
Features behind flags can be gradually rolled out, typically:
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: reference
|
|||
|
||||
These are notes and screenshots regarding Group SAML and SCIM that the GitLab Support Team sometimes uses while troubleshooting, but which do not fit into the official documentation. GitLab is making this public, so that anyone can make use of the Support team’s collected knowledge.
|
||||
|
||||
Please refer to GitLab's [Group SAML](../../user/group/saml_sso/index.md) docs for information on the feature and how to set it up.
|
||||
Please refer to the GitLab [Group SAML](../../user/group/saml_sso/index.md) docs for information on the feature and how to set it up.
|
||||
|
||||
When troubleshooting a SAML configuration, GitLab team members will frequently start with the [SAML troubleshooting section](../../user/group/saml_sso/index.md#troubleshooting).
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16647) in GitLab 12.7.
|
||||
|
||||
Appearance API allows you to maintain GitLab's appearance as if using the GitLab UI at
|
||||
`/admin/appearance`. The API requires administrator privileges.
|
||||
The appearance API allows you to maintain the appearance of GitLab as if
|
||||
you're using the GitLab UI at `/admin/appearance`. The API requires
|
||||
administrator privileges.
|
||||
|
||||
## Get current appearance configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Content specific to the GitLab Team should instead be included in the [Handbook]
|
|||
|
||||
For information on using GitLab to work on your own software projects, see the [GitLab user documentation](../user/index.md).
|
||||
|
||||
For information on working with GitLab's API, see the [API documentation](../api/README.md).
|
||||
For information on working with the GitLab APIs, see the [API documentation](../api/README.md).
|
||||
|
||||
For information on how to install, configure, update, and upgrade your own GitLab instance, see the [administration documentation](../administration/index.md).
|
||||
|
||||
## Get started
|
||||
|
||||
- Set up GitLab's development environment with [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md)
|
||||
- Set up the GitLab development environment with [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md)
|
||||
- [GitLab contributing guide](contributing/index.md)
|
||||
- [Issues workflow](contributing/issue_workflow.md) for more information on:
|
||||
- Issue tracker guidelines.
|
||||
|
|
@ -66,7 +66,7 @@ Complementary reads:
|
|||
|
||||
### Development guidelines review
|
||||
|
||||
When you submit a change to GitLab's development guidelines, request a review
|
||||
When you submit a change to the GitLab development guidelines, request a review
|
||||
from:
|
||||
|
||||
- A member of your team or group, to check for technical accuracy.
|
||||
|
|
|
|||
|
|
@ -410,8 +410,8 @@ in the regression issue as fixes are addressed.
|
|||
|
||||
## Technical and UX debt
|
||||
|
||||
In order to track things that can be improved in GitLab's codebase,
|
||||
we use the ~"technical debt" label in [GitLab's issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
|
||||
In order to track things that can be improved in the GitLab codebase,
|
||||
we use the ~"technical debt" label in the [GitLab issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
|
||||
For missed user experience requirements, we use the ~"UX debt" label.
|
||||
|
||||
These labels should be added to issues that describe things that can be improved,
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ the contribution acceptance criteria below:
|
|||
instructions for help if the "license-finder" test fails with a
|
||||
`Dependencies that need approval` error. Also, make the reviewer aware of the new
|
||||
library and explain why you need it.
|
||||
1. The merge request meets GitLab's [definition of done](#definition-of-done), below.
|
||||
1. The merge request meets the GitLab [definition of done](#definition-of-done), below.
|
||||
|
||||
## Definition of done
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: reference, dev
|
|||
stage: none
|
||||
group: Development
|
||||
info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
|
||||
description: "Writing styles, markup, formatting, and other standards for GitLab's RESTful APIs."
|
||||
description: "Writing styles, markup, formatting, and other standards for the GitLab RESTful APIs."
|
||||
---
|
||||
|
||||
# RESTful API
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ More about fragments:
|
|||
|
||||
## Global IDs
|
||||
|
||||
GitLab's GraphQL API expresses `id` fields as Global IDs rather than the PostgreSQL
|
||||
The GitLab GraphQL API expresses `id` fields as Global IDs rather than the PostgreSQL
|
||||
primary key `id`. Global ID is [a convention](https://graphql.org/learn/global-object-identification/)
|
||||
used for caching and fetching in client-side libraries.
|
||||
|
||||
|
|
@ -411,7 +411,7 @@ handleClick() {
|
|||
|
||||
### Working with pagination
|
||||
|
||||
GitLab's GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/pagination/overview/#cursor-based)
|
||||
The GitLab GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/pagination/overview/#cursor-based)
|
||||
for connection types. This means a "cursor" is used to keep track of where in the data
|
||||
set the next items should be fetched from. [GraphQL Ruby Connection Concepts](https://graphql-ruby.org/pagination/connection_concepts.html)
|
||||
is a good overview and introduction to connections.
|
||||
|
|
@ -1200,7 +1200,7 @@ describe('My Index test with `createMockApollo`', () => {
|
|||
|
||||
## Handling errors
|
||||
|
||||
GitLab's GraphQL mutations currently have two distinct error modes: [Top-level](#top-level-errors) and [errors-as-data](#errors-as-data).
|
||||
The GitLab GraphQL mutations currently have two distinct error modes: [Top-level](#top-level-errors) and [errors-as-data](#errors-as-data).
|
||||
|
||||
When utilising a GraphQL mutation, we must consider handling **both of these error modes** to ensure that the user receives the appropriate feedback when an error occurs.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ _before_ the code is being deployed.
|
|||
This allows you to separate rolling out a feature from a deploy, making it
|
||||
easier to measure the impact of both separately.
|
||||
|
||||
GitLab's feature library (using
|
||||
The GitLab feature library (using
|
||||
[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
|
||||
Flags process](process.md) guide) supports rolling out changes to a percentage of
|
||||
time to users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md).
|
||||
|
|
@ -238,7 +238,7 @@ The issue is created in the
|
|||
project, and it will at minimum log the Slack handle of person enabling
|
||||
a feature flag, the time, and the name of the flag being changed.
|
||||
|
||||
The issue is then also posted to GitLab's internal
|
||||
The issue is then also posted to the GitLab internal
|
||||
[Grafana dashboard](https://dashboards.gitlab.net/) as an annotation
|
||||
marker to make the change even more visible.
|
||||
|
||||
|
|
|
|||
|
|
@ -46,11 +46,11 @@ This is the default type used when calling `Feature.enabled?`.
|
|||
### `ops` type
|
||||
|
||||
`ops` feature flags are long-lived feature flags that control operational aspects
|
||||
of GitLab's behavior. For example, feature flags that disable features that might
|
||||
of GitLab product behavior. For example, feature flags that disable features that might
|
||||
have a performance impact, like special Sidekiq worker behavior.
|
||||
|
||||
`ops` feature flags likely do not have rollout issues, as it is hard to
|
||||
predict when they will be enabled or disabled.
|
||||
predict when they are enabled or disabled.
|
||||
|
||||
To use `ops` feature flags, you must append `type: :ops` to `Feature.enabled?`
|
||||
invocations:
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ they are new features or performance improvements. By using feature flags,
|
|||
you can determine the impact of GitLab-directed changes, while still being able
|
||||
to disable those changes without having to revert an entire release.
|
||||
|
||||
Before using feature flags for GitLab's development, review the following development guides:
|
||||
Before using feature flags for GitLab development, review the following development guides:
|
||||
|
||||
NOTE:
|
||||
The feature flags used by GitLab to deploy its own features **are not** the same
|
||||
as the [feature flags offered as part of the product](../../operations/feature_flags.md).
|
||||
|
||||
For an overview about starting with feature flags in GitLab's development,
|
||||
For an overview about starting with feature flags in GitLab development,
|
||||
use this [training template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/issue_templates/feature-flag-training.md).
|
||||
|
||||
Development guides:
|
||||
|
|
|
|||
|
|
@ -71,8 +71,8 @@ The following example shows a basic request/response flow between the following
|
|||
|
||||
- Snowplow JS / Ruby Trackers on GitLab.com
|
||||
- [GitLab.com Snowplow Collector](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/snowplow/index.md)
|
||||
- GitLab's S3 Bucket
|
||||
- GitLab's Snowflake Data Warehouse
|
||||
- The GitLab S3 Bucket
|
||||
- The GitLab Snowflake Data Warehouse
|
||||
- Sisense:
|
||||
|
||||
```mermaid
|
||||
|
|
@ -465,7 +465,7 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
|
|||
```ruby
|
||||
Gitlab::Tracking.self_describing_event('iglu:com.gitlab/pageview_context/jsonschema/1-0-0', data: { page_type: 'MY_TYPE' }, context: nil)
|
||||
```
|
||||
|
||||
|
||||
1. Navigate to `localhost:9090/micro/good` to see the event.
|
||||
|
||||
### Snowplow Mini
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ production: &base
|
|||
|
||||
## Usage Ping request flow
|
||||
|
||||
The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, GitLab's S3 Bucket, GitLab's Snowflake Data Warehouse, and Sisense:
|
||||
The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Sisense:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
|
|||
|
|
@ -448,7 +448,7 @@ instead of 30+ seconds in case of a regular `spec_helper`.
|
|||
|
||||
### `subject` and `let` variables
|
||||
|
||||
GitLab's RSpec suite has made extensive use of `let`(along with its strict, non-lazy
|
||||
The GitLab RSpec suite has made extensive use of `let`(along with its strict, non-lazy
|
||||
version `let!`) variables to reduce duplication. However, this sometimes [comes at the cost of clarity](https://thoughtbot.com/blog/lets-not),
|
||||
so we need to set some guidelines for their use going forward:
|
||||
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ 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)
|
||||
attribute is used as the UID in the GitLab [LDAP configuration](../administration/auth/ldap/index.md#configuration)
|
||||
but for Active Directory, this should be `sAMAccountName`.
|
||||
|
||||
The Kerberos realm must match the domain part of the LDAP user's Distinguished
|
||||
|
|
|
|||
|
|
@ -234,8 +234,9 @@ key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email addres
|
|||
|
||||
## Testing that everything is set up correctly
|
||||
|
||||
To test whether your SSH key was added correctly, run the following command in
|
||||
your terminal (replacing `gitlab.com` with your GitLab's instance domain):
|
||||
To test whether your SSH key was added correctly, run the following
|
||||
command in your terminal (replace `gitlab.com` with the domain of
|
||||
your GitLab instance):
|
||||
|
||||
```shell
|
||||
ssh -T git@gitlab.com
|
||||
|
|
@ -260,8 +261,8 @@ section to make sure you're connecting to the correct server. For example, you c
|
|||
the ECDSA key fingerprint shown above in the linked section.
|
||||
|
||||
Once added to the list of known hosts, you should validate the
|
||||
authenticity of GitLab's host again. Run the above command once more, and
|
||||
you should only receive a _Welcome to GitLab, `@username`!_ message.
|
||||
authenticity of the GitLab host, once again. Run the above command
|
||||
again, and you should receive a _Welcome to GitLab, `@username`!_ message.
|
||||
|
||||
If the welcome message doesn't appear, you can troubleshoot the problem by running `ssh`
|
||||
in verbose mode with the following command:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ System for Cross-domain Identity Management (SCIM), is an open standard that ena
|
|||
automation of user provisioning. When SCIM is provisioned for a GitLab group, membership of
|
||||
that group is synchronized between GitLab and the identity provider.
|
||||
|
||||
GitLab's [SCIM API](../../../api/scim.md) implements part of [the RFC7644 protocol](https://tools.ietf.org/html/rfc7644).
|
||||
The GitLab [SCIM API](../../../api/scim.md) implements part of [the RFC7644 protocol](https://tools.ietf.org/html/rfc7644).
|
||||
|
||||
## Features
|
||||
|
||||
|
|
@ -240,7 +240,7 @@ To see how the `external_uid` compares to the value returned as the SAML NameId,
|
|||
|
||||
Whether the value was changed or you need to map to a different field, ensure `id`, `externalId`, and `NameId` all map to the same field.
|
||||
|
||||
If GitLab's `externalId` doesn't match the SAML NameId, it will need to be updated in order for the user to log in. Ideally your identity provider will be configured to do such an update, but in some cases it may be unable to do so, such as when looking up a user fails due to an ID change.
|
||||
If the GitLab `externalId` doesn't match the SAML NameId, it needs to be updated in order for the user to sign in. Ideally your identity provider is configured to do such an update, but in some cases it may be unable to do so, such as when looking up a user fails due to an ID change.
|
||||
|
||||
Be cautious if you revise the fields used by your SCIM identity provider, typically `id` and `externalId`.
|
||||
We use these IDs to look up users. If the identity provider does not know the current values for these fields,
|
||||
|
|
|
|||
|
|
@ -277,7 +277,7 @@ applications and U2F / WebAuthn devices.
|
|||
|
||||
When 2FA is enabled, you can no longer use your normal account password to
|
||||
authenticate with Git over HTTPS on the command line or when using
|
||||
[GitLab's API](../../../api/README.md). You must use a
|
||||
the [GitLab API](../../../api/README.md). You must use a
|
||||
[personal access token](../personal_access_tokens.md) instead.
|
||||
|
||||
## Recovery options
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ module Gitlab
|
|||
def context_by_arguments
|
||||
@context_by_arguments ||= objects.each_with_object({}) do |object, result|
|
||||
arguments = Array.wrap(arguments_proc.call(object))
|
||||
context = Gitlab::ApplicationContext.new(context_proc.call(object))
|
||||
context = Gitlab::ApplicationContext.new(**context_proc.call(object))
|
||||
|
||||
result[arguments] = context
|
||||
end
|
||||
|
|
|
|||
|
|
@ -81,6 +81,9 @@ module Gitlab
|
|||
},
|
||||
trimmed_skip_trial_copy: {
|
||||
tracking_category: 'Growth::Conversion::Experiment::TrimmedSkipTrialCopy'
|
||||
},
|
||||
trial_registration_with_social_signin: {
|
||||
tracking_category: 'Growth::Conversion::Experiment::TrialRegistrationWithSocialSigning'
|
||||
}
|
||||
}.freeze
|
||||
|
||||
|
|
|
|||
|
|
@ -99,6 +99,22 @@ RSpec.describe AuthHelper do
|
|||
end
|
||||
end
|
||||
|
||||
describe 'experiment_enabled_button_based_providers' do
|
||||
it 'returns the intersection set of github & google_oauth2 with enabled providers' do
|
||||
allow(helper).to receive(:enabled_button_based_providers) { %w(twitter github google_oauth2) }
|
||||
|
||||
expect(helper.experiment_enabled_button_based_providers).to eq(%w(github google_oauth2))
|
||||
|
||||
allow(helper).to receive(:enabled_button_based_providers) { %w(google_oauth2 bitbucket) }
|
||||
|
||||
expect(helper.experiment_enabled_button_based_providers).to eq(%w(google_oauth2))
|
||||
|
||||
allow(helper).to receive(:enabled_button_based_providers) { %w(bitbucket) }
|
||||
|
||||
expect(helper.experiment_enabled_button_based_providers).to be_empty
|
||||
end
|
||||
end
|
||||
|
||||
describe 'button_based_providers_enabled?' do
|
||||
before do
|
||||
allow(helper).to receive(:auth_providers) { [:twitter, :github] }
|
||||
|
|
|
|||
|
|
@ -29,34 +29,4 @@ RSpec.describe Ci::CompareAccessibilityReportsService do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#latest?' do
|
||||
subject { service.latest?(base_pipeline, head_pipeline, data) }
|
||||
|
||||
let!(:base_pipeline) { nil }
|
||||
let!(:head_pipeline) { create(:ci_pipeline, :with_accessibility_reports, project: project) }
|
||||
let!(:key) { service.send(:key, base_pipeline, head_pipeline) }
|
||||
|
||||
context 'when cache key is latest' do
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_truthy }
|
||||
end
|
||||
|
||||
context 'when cache key is outdated' do
|
||||
before do
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
end
|
||||
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
|
||||
context 'when cache key is empty' do
|
||||
let(:data) { { key: nil } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -29,34 +29,4 @@ RSpec.describe Ci::CompareCodequalityReportsService do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#latest?' do
|
||||
subject { service.latest?(base_pipeline, head_pipeline, data) }
|
||||
|
||||
let!(:base_pipeline) { nil }
|
||||
let!(:head_pipeline) { create(:ci_pipeline, :with_codequality_reports, project: project) }
|
||||
let!(:key) { service.send(:key, base_pipeline, head_pipeline) }
|
||||
|
||||
context 'when cache key is latest' do
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_truthy }
|
||||
end
|
||||
|
||||
context 'when cache key is outdated' do
|
||||
before do
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
end
|
||||
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
|
||||
context 'when cache key is empty' do
|
||||
let(:data) { { key: nil } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,38 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Ci::CompareReportsBaseService do
|
||||
let(:service) { described_class.new(project) }
|
||||
let(:project) { create(:project, :repository) }
|
||||
|
||||
describe '#latest?' do
|
||||
subject { service.latest?(base_pipeline, head_pipeline, data) }
|
||||
|
||||
let!(:base_pipeline) { nil }
|
||||
let!(:head_pipeline) { create(:ci_pipeline, :with_test_reports, project: project) }
|
||||
let!(:key) { service.send(:key, base_pipeline, head_pipeline) }
|
||||
|
||||
context 'when cache key is latest' do
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_truthy }
|
||||
end
|
||||
|
||||
context 'when cache key is outdated' do
|
||||
before do
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
end
|
||||
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
|
||||
context 'when cache key is empty' do
|
||||
let(:data) { { key: nil } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -80,34 +80,4 @@ RSpec.describe Ci::CompareTestReportsService do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#latest?' do
|
||||
subject { service.latest?(base_pipeline, head_pipeline, data) }
|
||||
|
||||
let!(:base_pipeline) { nil }
|
||||
let!(:head_pipeline) { create(:ci_pipeline, :with_test_reports, project: project) }
|
||||
let!(:key) { service.send(:key, base_pipeline, head_pipeline) }
|
||||
|
||||
context 'when cache key is latest' do
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_truthy }
|
||||
end
|
||||
|
||||
context 'when cache key is outdated' do
|
||||
before do
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
end
|
||||
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
|
||||
context 'when cache key is empty' do
|
||||
let(:data) { { key: nil } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -52,34 +52,4 @@ RSpec.describe Ci::GenerateCoverageReportsService do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#latest?' do
|
||||
subject { service.latest?(base_pipeline, head_pipeline, data) }
|
||||
|
||||
let!(:base_pipeline) { nil }
|
||||
let!(:head_pipeline) { create(:ci_pipeline, :with_test_reports, project: project) }
|
||||
let!(:key) { service.send(:key, base_pipeline, head_pipeline) }
|
||||
|
||||
context 'when cache key is latest' do
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_truthy }
|
||||
end
|
||||
|
||||
context 'when cache key is outdated' do
|
||||
before do
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
end
|
||||
|
||||
let(:data) { { key: key } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
|
||||
context 'when cache key is empty' do
|
||||
let(:data) { { key: nil } }
|
||||
|
||||
it { is_expected.to be_falsy }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -64,33 +64,4 @@ RSpec.describe Ci::GenerateTerraformReportsService do
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#latest?' do
|
||||
let_it_be(:head_pipeline) { create(:ci_pipeline, :with_test_reports, project: project) }
|
||||
|
||||
subject { described_class.new(project) }
|
||||
|
||||
it 'returns true when cache key is latest' do
|
||||
cache_key = subject.send(:key, nil, head_pipeline)
|
||||
|
||||
result = subject.latest?(nil, head_pipeline, key: cache_key)
|
||||
|
||||
expect(result).to eq(true)
|
||||
end
|
||||
|
||||
it 'returns false when cache key is outdated' do
|
||||
cache_key = subject.send(:key, nil, head_pipeline)
|
||||
head_pipeline.update_column(:updated_at, 10.minutes.ago)
|
||||
|
||||
result = subject.latest?(nil, head_pipeline, key: cache_key)
|
||||
|
||||
expect(result).to eq(false)
|
||||
end
|
||||
|
||||
it 'returns false when cache key is nil' do
|
||||
result = subject.latest?(nil, head_pipeline, key: nil)
|
||||
|
||||
expect(result).to eq(false)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue