Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-12-10 03:09:53 +00:00
parent d8995bd33f
commit a8b811acdf
40 changed files with 131 additions and 209 deletions

View file

@ -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

View file

@ -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)

View file

@ -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?

View file

@ -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

View file

@ -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'

View file

@ -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)

View file

@ -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

View file

@ -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")

View file

@ -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
&nbsp;

View file

@ -20,7 +20,7 @@
&middot;
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
&nbsp;

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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:

View file

@ -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 teams 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).

View file

@ -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

View file

@ -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.

View file

@ -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,

View file

@ -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

View file

@ -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

View file

@ -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.

View file

@ -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.

View file

@ -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:

View file

@ -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:

View file

@ -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

View file

@ -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

View file

@ -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:

View file

@ -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

View file

@ -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:

View file

@ -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,

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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] }

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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