Commit 0d0cddc9 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 6044caed
......@@ -25,13 +25,12 @@ cache gems:
dont-interrupt-me:
extends: .setup:rules:dont-interrupt-me
stage: prepare
stage: sync
image: alpine:edge
interruptible: false
allow_failure: true
variables:
GIT_STRATEGY: none
dependencies: []
script:
- echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
......
......@@ -97,6 +97,7 @@
"Prometheus",
"Puma",
"Python",
"Rake",
"Redis",
"Redmine",
"reCAPTCHA",
......
......@@ -7,6 +7,10 @@ require:
- ./rubocop/rubocop
- rubocop-rspec
inherit_mode:
merge:
- Include
AllCops:
TargetRubyVersion: 2.6
TargetRailsVersion: 5.0
......@@ -161,6 +165,14 @@ Rails/ApplicationRecord:
- ee/db/**/*.rb
- ee/spec/**/*.rb
Rails/FindBy:
Enabled: true
Include:
- 'ee/app/**/*.rb'
- 'ee/lib/**/*.rb'
- 'spec/**/*.rb'
- 'ee/spec/**/*.rb'
# GitLab ###################################################################
Gitlab/ModuleWithInstanceVariables:
......@@ -205,7 +217,6 @@ Gitlab/DuplicateSpecLocation:
- ee/spec/helpers/auth_helper_spec.rb
- ee/spec/lib/gitlab/gl_repository_spec.rb
- ee/spec/models/namespace_spec.rb
- ee/spec/models/note_spec.rb
- ee/spec/serializers/environment_entity_spec.rb
- ee/spec/services/issues/create_service_spec.rb
- ee/spec/services/merge_requests/create_service_spec.rb
......@@ -214,7 +225,6 @@ Gitlab/DuplicateSpecLocation:
- ee/spec/services/system_hooks_service_spec.rb
- ee/spec/helpers/ee/auth_helper_spec.rb
- ee/spec/models/ee/namespace_spec.rb
- ee/spec/models/ee/note_spec.rb
- ee/spec/serializers/ee/environment_entity_spec.rb
- ee/spec/services/ee/issues/create_service_spec.rb
- ee/spec/services/ee/merge_requests/create_service_spec.rb
......
......@@ -366,7 +366,7 @@ group :development, :test do
gem 'spring', '~> 2.0.0'
gem 'spring-commands-rspec', '~> 1.0.4'
gem 'gitlab-styles', '~> 3.1.0', require: false
gem 'gitlab-styles', '~> 3.2.0', require: false
# Pin these dependencies, otherwise a new rule could break the CI pipelines
gem 'rubocop', '~> 0.74.0'
gem 'rubocop-performance', '~> 1.4.1'
......
......@@ -398,7 +398,7 @@ GEM
gitlab-puma (>= 2.7, < 5)
gitlab-sidekiq-fetcher (0.5.2)
sidekiq (~> 5)
gitlab-styles (3.1.0)
gitlab-styles (3.2.0)
rubocop (~> 0.74.0)
rubocop-gitlab-security (~> 0.1.0)
rubocop-performance (~> 1.4.1)
......@@ -1240,7 +1240,7 @@ DEPENDENCIES
gitlab-puma (~> 4.3.3.gitlab.2)
gitlab-puma_worker_killer (~> 0.1.1.gitlab.1)
gitlab-sidekiq-fetcher (= 0.5.2)
gitlab-styles (~> 3.1.0)
gitlab-styles (~> 3.2.0)
gitlab_chronic_duration (~> 0.10.6.2)
gitlab_omniauth-ldap (~> 2.1.1)
gon (~> 6.2)
......
......@@ -38,7 +38,8 @@ module EnvironmentsHelper
"tags-path" => project_tags_path(project),
"has-metrics" => "#{environment.has_metrics?}",
"prometheus-status" => "#{environment.prometheus_status}",
"external-dashboard-url" => project.metrics_setting_external_dashboard_url
"external-dashboard-url" => project.metrics_setting_external_dashboard_url,
"environment-state" => "#{environment.state}"
}
end
......
......@@ -257,7 +257,9 @@ class Member < ApplicationRecord
def retrieve_user(user)
return user if user.is_a?(User)
User.find_by(id: user) || User.find_by(email: user) || user
return User.find_by(id: user) if user.is_a?(Integer)
User.find_by(email: user) || user
end
def retrieve_member(source, user, existing_members)
......
---
title: Add environment-state flag to metrics data
merge_request: 28237
author:
type: added
---
title: Fix bug inviting members whose emails start with numbers
merge_request: 27848
author: Lee Tickett
type: fixed
---
title: Fix rake gitlab:setup failing on new installs
merge_request: 28270
author:
type: fixed
......@@ -311,7 +311,7 @@ things to check to debug the situation.
- You've waited an hour or [the configured
interval](ldap-ee.md#adjusting-ldap-group-sync-schedule) for the group to
sync. To speed up the process, either go to the GitLab group **Settings ->
Members** and press **Sync now** (sync one group) or [run the group sync rake
Members** and press **Sync now** (sync one group) or [run the group sync Rake
task][group-sync-rake] (sync all groups).
If all of the above looks good, jump in to a little more advanced debugging in
......@@ -351,7 +351,7 @@ GitLab syncs the `admin_group`.
#### Sync all groups **(STARTER ONLY)**
NOTE: **NOTE:**
To sync all groups manually when debugging is unnecessary, [use the rake
To sync all groups manually when debugging is unnecessary, [use the Rake
task][group-sync-rake] instead.
The output from a manual [group sync][group-sync] can show you what happens
......@@ -541,7 +541,7 @@ for each of these users.
### LDAP check
The [rake task to check LDAP][ldap-check] is a valuable tool
The [Rake task to check LDAP][ldap-check] is a valuable tool
to help determine whether GitLab can successfully establish a connection to
LDAP and can get so far as to even read users.
......@@ -550,7 +550,7 @@ with your configuration or a firewall blocking the connection.
- Ensure you don't have a firewall blocking the
connection, and that the LDAP server is accessible to the GitLab host.
- Look for an error message in the rake check output, which may lead to your LDAP configuration to
- Look for an error message in the Rake check output, which may lead to your LDAP configuration to
confirm that the configuration values (specifically `host`, `port`, `bind_dn`, and
`password`) are correct.
- Look for [errors](#connection) in [the logs](#gitlab-logs) to further debug connection failures.
......
......@@ -88,9 +88,9 @@ end
## Validation
Writing your own file hook can be tricky and it's easier if you can check it
without altering the system. A rake task is provided so that you can use it
without altering the system. A Rake task is provided so that you can use it
in a staging environment to test your file hook before using it in production.
The rake task will use a sample data and execute each of file hook. The output
The Rake task will use a sample data and execute each of file hook. The output
should be enough to determine if the system sees your file hook and if it was
executed without errors.
......
......@@ -115,7 +115,7 @@ Feature.enable('geo_repository_reverification')
Geo actively try to correct verification failures marking the repository to
be resynced with a back-off period. If you want to reset them manually, this
rake task marks projects where verification has failed or the checksum mismatch
Rake task marks projects where verification has failed or the checksum mismatch
to be resynced without the back-off period:
For repositories:
......
......@@ -37,7 +37,7 @@ For information on how to resolve common errors reported from the UI, see
If the UI is not working, or you are unable to log in, you can run the Geo
health check manually to get this information as well as a few more details.
This rake task can be run on an app node in the **primary** or **secondary**
This Rake task can be run on an app node in the **primary** or **secondary**
Geo nodes:
```shell
......@@ -70,7 +70,7 @@ All projects are in hashed storage? ... yes
Checking Geo ... Finished
```
Current sync information can be found manually by running this rake task on any
Current sync information can be found manually by running this Rake task on any
**secondary** app node:
```shell
......@@ -147,9 +147,9 @@ This machine's Geo node name matches a database record ... no
doc/administration/geo/replication/troubleshooting.md#can-geo-detect-the-current-node-correctly
```
## Fixing errors found when running the Geo check rake task
## Fixing errors found when running the Geo check Rake task
When running this rake task, you may see errors if the nodes are not properly configured:
When running this Rake task, you may see errors if the nodes are not properly configured:
```shell
sudo gitlab-rake gitlab:geo:check
......@@ -789,7 +789,7 @@ sudo gitlab-rake geo:db:refresh_foreign_tables
## Expired artifacts
If you notice for some reason there are more artifacts on the Geo
secondary node than on the Geo primary node, you can use the rake task
secondary node than on the Geo primary node, you can use the Rake task
to [cleanup orphan artifact files](../../../raketasks/cleanup.md#remove-orphan-artifact-files).
On a Geo **secondary** node, this command will also clean up all Geo
......
......@@ -145,7 +145,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [Repository checks](repository_checks.md): Periodic Git repository checks.
- [Repository storage paths](repository_storage_paths.md): Manage the paths used to store repositories.
- [Repository storage types](repository_storage_types.md): Information about the different repository storage types.
- [Repository storage rake tasks](raketasks/storage.md): A collection of rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage.
- [Repository storage Rake tasks](raketasks/storage.md): A collection of Rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage.
- [Limit repository size](../user/admin_area/settings/account_and_limit_settings.md): Set a hard limit for your repositories' size. **(STARTER ONLY)**
- [Static objects external storage](static_objects_external_storage.md): Set external storage for static objects in a repository.
......
......@@ -136,7 +136,7 @@ and comparing the output of the returned headers.
There are two ways to manually do the same thing as automatic uploading (described above).
**Option 1: rake task**
**Option 1: Rake task**
```shell
rake gitlab:lfs:migrate
......
......@@ -20,7 +20,7 @@ to prevent data integrity issues. However, if a Git operation is interrupted the
locks may not be cleaned up properly.
The following symptoms may indicate a problem with repository integrity. If users
experience these symptoms you may use the rake tasks described below to determine
experience these symptoms you may use the Rake tasks described below to determine
exactly which repositories are causing the trouble.
- Receiving an error when trying to push code - `remote: error: cannot lock ref`
......
......@@ -59,7 +59,7 @@ sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production
## Remove orphaned project registries
Under certain conditions your project registry can contain obsolete records, you
can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
can remove them using the Rake task `geo:run_orphaned_project_registry_cleaner`:
**Omnibus Installation**
......
......@@ -4,7 +4,7 @@
In order to retrieve and import GitHub repositories, you will need a
[GitHub personal access token](https://github.com/settings/tokens).
A username should be passed as the second argument to the rake task
A username should be passed as the second argument to the Rake task
which will become the owner of the project. You can resume an import
with the same command.
......
......@@ -50,7 +50,7 @@ Git: /usr/bin/git
## Check GitLab configuration
Runs the following rake tasks:
Runs the following Rake tasks:
- `gitlab:gitlab_shell:check`
- `gitlab:gitaly:check`
......@@ -209,7 +209,7 @@ sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
## Check TCP connectivity to a remote site
Sometimes you need to know if your GitLab installation can connect to a TCP
service on another machine - perhaps a PostgreSQL or HTTPS server. A rake task
service on another machine - perhaps a PostgreSQL or HTTPS server. A Rake task
is included to help you with this:
**Omnibus Installation**
......@@ -258,7 +258,7 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
See the [upgrade documentation](../../update/README.md#checking-for-background-migrations-before-upgrading)
for how to check that migrations are complete when upgrading GitLab.
To check the status of specific migrations, you can use the following rake task:
To check the status of specific migrations, you can use the following Rake task:
```shell
sudo gitlab-rake db:migrate:status
......
# Repository Storage Rake Tasks
This is a collection of rake tasks you can use to help you list and migrate
This is a collection of Rake tasks you can use to help you list and migrate
existing projects and attachments associated with it from Legacy storage to
the new Hashed storage type.
......@@ -46,7 +46,7 @@ Any error or warning will be logged in Sidekiq's log file.
NOTE: **Note:**
If Geo is enabled, each project that is successfully migrated generates an event to replicate the changes on any **secondary** nodes.
You only need the `gitlab:storage:migrate_to_hashed` rake task to migrate your repositories, but we have additional
You only need the `gitlab:storage:migrate_to_hashed` Rake task to migrate your repositories, but we have additional
commands below that helps you inspect projects and attachments in both legacy and hashed storage.
## Rollback from Hashed storage to Legacy storage
......
......@@ -7,12 +7,12 @@ After [configuring the object storage](../../uploads.md#using-object-storage-cor
>**Note:**
All of the processing will be done in a background worker and requires **no downtime**.
### All-in-one rake task
### All-in-one Rake task
GitLab provides a wrapper rake task that migrates all uploaded files - avatars,
GitLab provides a wrapper Rake task that migrates all uploaded files - avatars,
logos, attachments, favicon, etc. - to object storage in one go. Under the hood,
it invokes individual rake tasks to migrate files falling under each of this
category one by one. The specifications of these individual rake tasks are
it invokes individual Rake tasks to migrate files falling under each of this
category one by one. The specifications of these individual Rake tasks are
described in the next section.
**Omnibus Installation**
......@@ -27,12 +27,12 @@ gitlab-rake "gitlab:uploads:migrate:all"
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all
```
### Individual rake tasks
### Individual Rake tasks
>**Note:**
If you already ran the rake task mentioned above, no need to run these individual rake tasks as that has been done automatically.
If you already ran the Rake task mentioned above, no need to run these individual Rake tasks as that has been done automatically.
The rake task uses 3 parameters to find uploads to migrate.
The Rake task uses 3 parameters to find uploads to migrate.
Parameter | Type | Description
--------- | ---- | -----------
......@@ -140,12 +140,12 @@ the migration. A configuration setting will be added soon to allow migrating
from object storage to local files with only a brief moment of downtime for configuration changes.
To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/30979).
### All-in-one rake task
### All-in-one Rake task
GitLab provides a wrapper rake task that migrates all uploaded files - avatars,
GitLab provides a wrapper Rake task that migrates all uploaded files - avatars,
logos, attachments, favicon, etc. - to local storage in one go. Under the hood,
it invokes individual rake tasks to migrate files falling under each of this
category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks),
it invokes individual Rake tasks to migrate files falling under each of this
category one by one. For details on these Rake tasks please [refer to the section above](#individual-rake-tasks),
keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`.
**Omnibus Installation**
......
......@@ -29,7 +29,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem
This command by default runs in dry mode and it doesn't remove EXIF data. It can be used for
checking if (and how many) images should be sanitized.
The rake task accepts following parameters.
The Rake task accepts following parameters.
Parameter | Type | Description
--------- | ---- | -----------
......@@ -41,7 +41,7 @@ Parameter | Type | Description
`since` | date | Run sanitization only for uploads newer than given date (e.g. `2019-05-01`)
If you have too many uploads, you can speed up sanitization by setting
`sleep_time` to a lower value or by running multiple rake tasks in parallel,
`sleep_time` to a lower value or by running multiple Rake tasks in parallel,
each with a separate range of upload IDs (by setting `start_id` and `stop_id`).
To run the command without dry mode and remove EXIF data from all uploads, you can use:
......@@ -58,7 +58,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem
Because the output of commands will be probably long, the output is written also into exif.log file.
If sanitization fails for an upload, an error message should be in the output of the rake task (typical reasons may
If sanitization fails for an upload, an error message should be in the output of the Rake task (typical reasons may
be that the file is missing in the storage or it's not a valid image). Please
[report](https://gitlab.com/gitlab-org/gitlab-foss/issues/new) any issues at `gitlab.com` and use
prefix 'EXIF' in issue title with the error output and (if possible) the image.
......@@ -162,7 +162,7 @@ either runs on the same machine as your repositories are located, or may login t
to access data (for example, a remote backup solution).
To schedule a complete rollout, see the
[rake task documentation for storage migration][rake/migrate-to-hashed] for instructions.
[Rake task documentation for storage migration][rake/migrate-to-hashed] for instructions.
If you do have any existing integration, you may want to do a small rollout first,
to validate. You can do so by specifying a range with the operation.
......@@ -186,7 +186,7 @@ projects:
1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
To schedule a complete rollback, see the
[rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
[Rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
The rollback task also supports specifying a range of Project IDs. Here is an example
of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
......
......@@ -15,7 +15,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
For Omnibus installations, run `gitlab-rake time:zones:all`.
NOTE: **Note:**
Currently, this rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
Currently, this Rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
## Changing time zone in Omnibus installations
......
......@@ -204,7 +204,7 @@ If it is, check on the Elasticsearch side to determine if the `gitlab-production
name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch
side and attempt to recreate it from the
[`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
rake task.
Rake task.
If you still encounter issues, try creating an index manually on the Elasticsearch
instance. The details of the index aren't important here, as we want to test if indices
......@@ -220,7 +220,7 @@ during the indexing of projects. If errors do occur, they will either stem from
something you are familiar with, contact GitLab support for guidance.
- Within the Elasticsearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your Elasticsearch admin.
If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following rake tasks:
If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following Rake tasks:
- [`sudo gitlab-rake gitlab:elastic:index_projects_status`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows the overall status)
- [`sudo gitlab-rake gitlab:elastic:projects_not_indexed`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows specific projects that are not indexed)
......
......@@ -117,7 +117,7 @@ and they will assist you with any issues you are having.
kubectl get events -w --namespace=gitlab
```
- Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner
- Most of the useful GitLab tools (console, Rake tasks, etc) are found in the task-runner
pod. You may enter it and run commands inside or run them from the outside:
```shell
......
......@@ -116,7 +116,7 @@ _The uploads are stored by default in
```
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
**In installations from source:**
......@@ -139,7 +139,7 @@ _The uploads are stored by default in
```
1. Save the file and [restart GitLab][] for the changes to take effect.
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
### Oracle Cloud S3 connection settings
......@@ -193,7 +193,7 @@ _The uploads are stored by default in
```
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
---
......@@ -224,7 +224,7 @@ _The uploads are stored by default in
```
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
[reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
[restart gitlab]: restart_gitlab.md#installations-from-source "How to restart GitLab"
......
......@@ -5,7 +5,7 @@
See also:
- [Project import/export documentation](../user/project/settings/import_export.md).
- [Project import/export administration rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)**
- [Project import/export administration Rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)**
## Schedule an export
......
......@@ -456,6 +456,33 @@ Example response:
}
```
## Collect release evidence **(PREMIUM ONLY)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
Create Evidence for an existing Release.
```plaintext
POST /projects/:id/releases/:tag_name/evidence
```
| Attribute | Type | Required | Description |
| ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
| `tag_name` | string | yes | The tag where the release will be created from. |
Example request:
```shell
curl --request POST --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/evidence"
```
Example response:
```json
200
```
## Update a release
Update a Release.
......
......@@ -725,7 +725,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
### Maintenance Tasks
[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides Rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance Rake tasks](../raketasks/maintenance.md).
In a nutshell, do the following:
```shell
......
......@@ -31,7 +31,7 @@ from the start of the merge request.
## Run Danger locally
A subset of the current checks can be run locally with the following rake task:
A subset of the current checks can be run locally with the following Rake task:
```shell
bin/rake danger_local
......
......@@ -25,7 +25,7 @@ Developers making significant changes to Elasticsearch queries should test their
See the [Elasticsearch GDK setup instructions](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/elasticsearch.md)
## Helpful rake tasks
## Helpful Rake tasks
- `gitlab:elastic:test:index_size`: Tells you how much space the current index is using, as well as how many documents are in the index.
- `gitlab:elastic:test:index_size_change`: Outputs index size, reindexes, and outputs index size again. Useful when testing improvements to indexing size.
......@@ -34,7 +34,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
## How does it work?
The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a Rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
After initial indexing is complete, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/topics/data-types#sorted-sets). A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html).
......
......@@ -56,7 +56,9 @@ The author then adds a comment to this piece of code and adds a link to the issu
```
- Track necessary events. See the [telemetry guide](../../telemetry/index.md) for details.
- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) in the
[appropriate channel](../feature_flags/controls.md#where-to-run-commands) to enable the feature flag and start the experiment.
For visibility, please also share any commands run against production in the `#s_growth` channel:
```shell
/chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
......
......@@ -50,9 +50,9 @@ In the case of Issues/MR/Notes Markdown attachments, there is a different approa
instead of basing the path into a mutable variable `:project_path_with_namespace`, it's possible to use the
hash of the project ID instead, if project migrates to the new approach (introduced in 10.2).
> Note: We provide an [all-in-one rake task] to migrate all uploads to object
> Note: We provide an [all-in-one Rake task] to migrate all uploads to object
> storage in one go. If a new Uploader class or model type is introduced, make
> sure you add a rake task invocation corresponding to it to the [category
> sure you add a Rake task invocation corresponding to it to the [category
> list].
### Path segments
......
......@@ -45,7 +45,7 @@ There is also an option to [import the project via GitHub](../user/project/impor
This method will take longer to import than the other methods and will depend on several factors. It's recommended to use the other methods.
### Importing via a rake task
### Importing via a Rake task
[`import.rake`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/import_export/import.rake) was introduced for importing large GitLab project exports.
......
......@@ -129,11 +129,11 @@ To run several tests inside one directory:
- `bin/rspec spec/requests/api/` for the rspec tests if you want to test API only
### Speed-up tests, rake tasks, and migrations
### Speed-up tests, Rake tasks, and migrations
[Spring](https://github.com/rails/spring) is a Rails application preloader. It
speeds up development by keeping your application running in the background so
you don't need to boot it every time you run a test, rake task or migration.
you don't need to boot it every time you run a test, Rake task or migration.
If you want to use it, you'll need to export the `ENABLE_SPRING` environment
variable to `1`:
......@@ -247,7 +247,7 @@ To generate GraphQL documentation based on the GitLab schema, run:
bundle exec rake gitlab:graphql:compile_docs
```
In its current state, the rake task:
In its current state, the Rake task:
- Generates output for GraphQL objects.
- Places the output at `doc/api/graphql/reference/index.md`.
......@@ -270,4 +270,4 @@ To generate GraphQL schema files based on the GitLab schema, run:
bundle exec rake gitlab:graphql:schema:dump
```
This uses graphql-ruby's built-in rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.
This uses graphql-ruby's built-in Rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.
......@@ -141,7 +141,7 @@ The following Elasticsearch settings are available:
| Parameter | Description |
| ----------------------------------------------------- | ----------- |
| `Elasticsearch indexing` | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
| `Elasticsearch indexing` | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special Rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
| `Search with Elasticsearch enabled` | Enables/disables using Elasticsearch in search. |
| `URL` | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
| `Number of Elasticsearch shards` | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
......@@ -174,7 +174,7 @@ If no namespaces or projects are selected, no Elasticsearch indexing will take p
CAUTION: **Warning**:
If you have already indexed your instance, you will have to regenerate the index in order to delete all existing data
for filtering to work correctly. To do this run the rake tasks `gitlab:elastic:create_empty_index` and
for filtering to work correctly. To do this run the Rake tasks `gitlab:elastic:create_empty_index` and
`gitlab:elastic:clear_index_status`. Afterwards, removing a namespace or a project from the list will delete the data
from the Elasticsearch index as expected.
......@@ -298,7 +298,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
This enqueues a Sidekiq job for each project that needs to be indexed.
You can view the jobs in **Admin Area > Monitoring > Background Jobs > Queues Tab**
and click `elastic_indexer`, or you can query indexing status using a rake task:
and click `elastic_indexer`, or you can query indexing status using a Rake task:
```shell
# Omnibus installations
......@@ -402,7 +402,7 @@ For repository and snippet files, GitLab will only index up to 1 MiB of content,
## GitLab Elasticsearch Rake Tasks
There are several rake tasks available to you via the command line:
There are several Rake tasks available to you via the command line:
- [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
- This is a wrapper task. It does the following:
......@@ -438,7 +438,7 @@ There are several rake tasks available to you via the command line:
### Environment Variables
In addition to the rake tasks, there are some environment variables that can be used to modify the process:
In addition to the Rake tasks, there are some environment variables that can be used to modify the process:
| Environment Variable | Data Type | What it does |
| -------------------- |:---------:| ---------------------------------------------------------------------------- |
......@@ -550,7 +550,7 @@ Here are some common pitfalls and how to overcome them:
- **I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything**
You will need to re-run all the rake tasks to re-index the database, repositories, and wikis.
You will need to re-run all the Rake tasks to re-index the database, repositories, and wikis.
- **The indexing process is taking a very long time**
......@@ -564,7 +564,7 @@ Here are some common pitfalls and how to overcome them:
When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could
happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them,
run the `gitlab:elastic:clear_locked_projects` rake task.
run the `gitlab:elastic:clear_locked_projects` Rake task.
- **"Can't specify parent if no parent field has been configured"**
......@@ -632,7 +632,7 @@ Here are some common pitfalls and how to overcome them:
```
You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
Once you have corrected the formatting of the URL, delete the index (via the [dedicated rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
### Reverting to basic search
......
......@@ -131,8 +131,8 @@ First upgrade your GitLab server to version 8.0:
After you update, go to the admin panel and temporarily disable CI. As
an administrator, go to **Admin Area** -> **Settings**, and under
**Continuous Integration** uncheck **Disable to prevent CI usage until rake
ci:migrate is run (8.0 only)**.
**Continuous Integration** uncheck **Disable to prevent CI usage until `rake
ci:migrate` is run (8.0 only)**.
### 3. CI settings are now in GitLab
......@@ -184,7 +184,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production
### 2. SQL data and build traces
Create your final CI data export. If you are converting from MySQL to
PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the Rake command. When
the command finishes it will print the path to your data export archive; you
will need this file later.
......
......@@ -19,6 +19,8 @@ The following are available Rake tasks:
|:-------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------|
| [Back up and restore](backup_restore.md) | Back up, restore, and migrate GitLab instances between servers. |
| [Clean up](cleanup.md) | Clean up unneeded items GitLab instances. |
| [Development](../development/rake_tasks.md) | Tasks for GitLab contributors. |
| [Elasticsearch](../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) | Maintain Elasticsearch in a GitLab instance. |
| [Enable namespaces](features.md) | Enable usernames and namespaces for user projects. |
| [General maintenance](../administration/raketasks/maintenance.md) | General maintenance and self-check tasks. |
| [Geo maintenance](../administration/raketasks/geo.md) **(PREMIUM ONLY)** | [Geo](../administration/geo/replication/index.md)-related maintenance. |
......
......@@ -109,7 +109,7 @@ kubectl exec -it <gitlab task-runner pod> backup-utility
Similarly to the Kubernetes case, if you have scaled out your GitLab
cluster to use multiple application servers, you should pick a
designated node (that won't be auto-scaled away) for running the
backup rake task. Because the backup rake task is tightly coupled to
backup Rake task. Because the backup Rake task is tightly coupled to
the main Rails application, this is typically a node on which you're
also running Unicorn/Puma and/or Sidekiq.
......@@ -171,7 +171,7 @@ the GitLab container according to the documentation, it should be under
`/srv/gitlab/config`.
For [GitLab Helm chart Installations](https://gitlab.com/gitlab-org/charts/gitlab) on a
Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.
Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.
You may also want to back up any TLS keys and certificates, and your
[SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
......@@ -819,7 +819,7 @@ a Kubernetes cluster, the restore task expects the restore directories to be emp
However, with docker and Kubernetes volume mounts, some system level directories
may be created at the volume roots, like `lost+found` directory found in Linux
operating systems. These directories are usually owned by `root`, which can
cause access permission errors since the restore rake task runs as `git` user.
cause access permission errors since the restore Rake task runs as `git` user.
So, to restore a GitLab installation, users have to confirm the restore target
directories are empty.
......@@ -875,8 +875,8 @@ to export / backup your data yourself from GitLab.com.
Issues are stored in the database. They can't be stored in Git itself.
To migrate your repositories from one server to another with an up-to-date version of
GitLab, you can use the [import rake task](import.md) to do a mass import of the
repository. Note that if you do an import rake task, rather than a backup restore, you
GitLab, you can use the [import Rake task](import.md) to do a mass import of the
repository. Note that if you do an import Rake task, rather than a backup restore, you
will have all your repositories, but not any other data.
## Troubleshooting
......@@ -893,7 +893,7 @@ psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING: no privileges were
Be advised that, backup is successfully restored in spite of these warnings.
The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
The Rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
Those objects have no influence on the database backup/restore but they give this annoying warning.
For more information see similar questions on PostgreSQL issue tracker[here](https://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](https://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).
......
......@@ -9,7 +9,7 @@ GitLab provides Rake tasks for cleaning up GitLab instances.
DANGER: **Danger:**
Do not run this within 12 hours of a GitLab upgrade. This is to ensure that all background migrations have finished, which otherwise may lead to data loss.
When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this rake task, you can remove invalid references from the database, which
When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this Rake task, you can remove invalid references from the database, which
will allow garbage collection of LFS files.
For example:
......@@ -36,7 +36,7 @@ By default, this task does not delete anything but shows how many file reference
delete. Run the command with `DRY_RUN=false` if you actually want to
delete the references. You can also use `LIMIT={number}` parameter to limit the number of deleted references.
Note that this rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected
Note that this Rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected
later (once a day). If you need to garbage collect them immediately, run
`rake gitlab:cleanup:orphan_lfs_files` described below.
......
......@@ -65,7 +65,7 @@ The following are important notes about 2FA:
## Disabling 2FA for everyone
There may be some special situations where you want to disable 2FA for everyone
even when forced 2FA is disabled. There is a rake task for that:
even when forced 2FA is disabled. There is a Rake task for that:
```shell
# Omnibus installations
......
......@@ -62,14 +62,14 @@ Sometimes we need to upgrade customers from old versions of GitLab to latest, so
- Users
- Groups
- Projects
- [Backup using our Backup rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system)
- [Backup using our Backup Rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system)
- [Upgrade to 5.0 source using our Upgrade documentation](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/4.2-to-5.0.md)
- [Upgrade to 5.1 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.0-to-5.1.md)
- [Upgrade to 6.0 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.1-to-6.0.md)
- [Upgrade to 7.14 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/6.x-or-7.x-to-7.14.md)
- [Perform the MySQL to PostgreSQL migration to convert your backup](../../update/mysql_to_postgresql.md)
- [Upgrade to Omnibus 7.14](https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation)
- [Restore backup using our Restore rake task](../../raketasks/backup_restore.md#restore)
- [Restore backup using our Restore Rake task](../../raketasks/backup_restore.md#restore)
- [Upgrade to latest EE](https://about.gitlab.com/update/)
- (GitLab inc. only) Acquire and apply a license for the Enterprise Edition product, ask in #support
- Perform a downgrade from [EE to CE](../../downgrade_ee_to_ce/README.md)
......
......@@ -147,7 +147,7 @@ puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
There is also a [rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations)
There is also a [Rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations)
for displaying the status of each database migration.
## Upgrading to a new major version
......
......@@ -45,7 +45,7 @@ need to do.
### GitLab 8.6+
Pass the version to a database rake task to manually mark the migration as
Pass the version to a database Rake task to manually mark the migration as
complete.
```shell
......@@ -56,7 +56,7 @@ sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857
sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
```
Once the migration is successfully marked, run the rake `db:migrate` task again.
Once the migration is successfully marked, run the Rake `db:migrate` task again.
You will likely have to repeat this process several times until all failed
migrations are marked complete.
......@@ -77,6 +77,6 @@ ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) V
exit
```
Once the migration is successfully marked, run the rake `db:migrate` task again.
Once the migration is successfully marked, run the Rake `db:migrate` task again.
You will likely have to repeat this process several times until all failed
migrations are marked complete.
......@@ -14,7 +14,7 @@ GitHub repositories using a [personal access token](#using-a-github-token),
but this method is not recommended because it cannot associate all user activity
(such as issues and pull requests) with matching GitLab users.
If you are an administrator of a self-managed GitLab instance, you can also use the
[GitHub rake task](../../../administration/raketasks/github_import.md) to import projects from
[GitHub Rake task](../../../administration/raketasks/github_import.md) to import projects from
GitHub without the constraints of a Sidekiq worker.
The following aspects of a project are imported:
......
......@@ -882,7 +882,7 @@ If the "No data found" screen continues to appear, it could be due to:
are not labeled correctly. To test this, connect to the Prometheus server and
[run a query](prometheus_library/kubernetes.md#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
with the name of your environment.
- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics rake task](../../../administration/raketasks/maintenance.md#import-common-metrics).
- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics Rake task](../../../administration/raketasks/maintenance.md#import-common-metrics).
[autodeploy]: ../../../topics/autodevops/index.md#auto-deploy
[kubernetes]: https://kubernetes.io
......
......@@ -244,16 +244,20 @@ You can also edit an existing tag to add release notes:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.6.
Each time a new release is created, specific related data is collected in
parallel. This dataset will be a snapshot this new release (including linked
milestones and issues) at moment of creation. Such collection of data will
provide a chain of custody and facilitate processes like external audits, for example.
Each time a release is created, GitLab takes a snapshot of data that's related to it.
This data is called Release Evidence. It includes linked milestones and issues, and
it is taken at moment the release is created. It provides a chain of custody and can
facilitate processes like external audits, for example.
The gathered evidence data is stored in the database upon creation of a new
release as a JSON object. In GitLab 12.6, a link to
the evidence data is provided for [each Release](#releases-list).
You can also [use the API](../../../api/releases/index.md#collect-release-evidence-premium-only) to
generate Release Evidence for an existing release. Because of this, [each release](#releases-list)
can have multiple Release Evidence snapshots. You can view the Release Evidence and
its details on the Release page.
Here is what this object can look like:
Release Evidence is stored as a JSON object, so you can compare evidence by using
commonly-available tools.
Here is an example of a Release Evidence object:
```json
{
......@@ -319,7 +323,14 @@ Please note that Release Evidence's data is collected regardless of this
feature flag, which only enables or disables the display of the data on the
Releases page.
### Scheduled Evidence creation
### Collect release evidence **(PREMIUM ONLY)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
Evidence collection can be initiated by using an [API call](../../../api/releases/index.md#collect-release-evidence-premium-only) at any time. Evidence snapshots are visible on
the Release page, along with the timestamp the Evidence was collected.
### Schedule release evidence collection
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8.
......
......@@ -11,7 +11,7 @@ The **GitLab import/export** button is displayed if the project import option is
See also:
- [Project import/export API](../../../api/project_import_export.md)
- [Project import/export administration rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)**
- [Project import/export administration Rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)**
- [Group import/export API](../../../api/group_import_export.md)
To set up a project import/export:
......
......@@ -14,6 +14,9 @@ class Feature
end
def server_feature_flags
# We need to check that both the DB connection and table exists
return {} unless ::Gitlab::Database.cached_table_exists?(FlipperFeature.table_name)
Feature.persisted_names
.select { |f| f.start_with?(PREFIX) }
.map do |f|
......
......@@ -93,12 +93,15 @@ module Gitlab
# Commit.last_for_path(repo, 'master', 'Gemfile')
#
def last_for_path(repo, ref, path = nil)
# rubocop: disable Rails/FindBy
# This is not where..first from ActiveRecord
where(
repo: repo,
ref: ref,
path: path,
limit: 1
).first
# rubocop: enable Rails/FindBy
end
# Get commits between two revspecs
......
......@@ -38,9 +38,8 @@ module Gitlab
identities = ::Identity.arel_table
User.select(:id)
.joins(:identities).where(identities[:provider].eq(:github)
.and(identities[:extern_uid].eq(id)))
.first
.joins(:identities)
.find_by(identities[:provider].eq(:github).and(identities[:extern_uid].eq(id)))
.try(:id)
end
# rubocop: enable CodeReuse/ActiveRecord
......
......@@ -33,7 +33,8 @@ describe EnvironmentsHelper do
'tags-path' => project_tags_path(project),
'has-metrics' => "#{environment.has_metrics?}",
'prometheus-status' => "#{environment.prometheus_status}",
'external-dashboard-url' => nil
'external-dashboard-url' => nil,
'environment-state' => environment.state
)
end
......@@ -46,5 +47,15 @@ describe EnvironmentsHelper do
expect(metrics_data['external-dashboard-url']).to eq('http://gitlab.com')
end
end
context 'when the environment is not available' do
before do
environment.stop
end
subject { metrics_data }
it { is_expected.to include('environment-state' => 'stopped') }
end
end
end
......@@ -32,5 +32,15 @@ describe Feature::Gitaly do
it { is_expected.to be_a(Hash) }
it { is_expected.to eq("gitaly-feature-mep-mep" => "true") }
context 'when table does not exist' do
before do
allow(::Gitlab::Database).to receive(:cached_table_exists?).and_return(false)
end
it 'returns an empty Hash' do
expect(subject).to eq({})
end
end
end
end
......@@ -39,7 +39,10 @@ describe Gitlab::Git::Tree, :seed_helper do
it { expect(dir.flat_path).to eq('encoding') }
context :subdir do
# rubocop: disable Rails/FindBy
# This is not ActiveRecord where..first
let(:subdir) { Gitlab::Git::Tree.where(repository, SeedRepo::Commit::ID, 'files').first }
# rubocop: enable Rails/FindBy
it { expect(subdir).to be_kind_of Gitlab::Git::Tree }
it { expect(subdir.id).to eq('a1e8f8d745cc87e3a9248358d9352bb7f9a0aeba') }
......@@ -50,7 +53,10 @@ describe Gitlab::Git::Tree, :seed_helper do
end
context :subdir_file do
# rubocop: disable Rails/FindBy
# This is not ActiveRecord where..first
let(:subdir_file) { Gitlab::Git::Tree.where(repository, SeedRepo::Commit::ID, 'files/ruby').first }
# rubocop: enable Rails/FindBy
it { expect(subdir_file).to be_kind_of Gitlab::Git::Tree }
it { expect(subdir_file.id).to eq('7e3e39ebb9b2bf433b4ad17313770fbe4051649c') }
......@@ -63,7 +69,10 @@ describe Gitlab::Git::Tree, :seed_helper do
context :flat_path do
let(:filename) { 'files/flat/path/correct/content.txt' }
let(:oid) { create_file(filename) }
# rubocop: disable Rails/FindBy
# This is not ActiveRecord where..first
let(:subdir_file) { Gitlab::Git::Tree.where(repository, oid, 'files/flat').first }
# rubocop: enable Rails/FindBy
let(:repository_rugged) { Rugged::Repository.new(File.join(SEED_STORAGE_PATH, TEST_REPO_PATH)) }
it { expect(subdir_file.flat_path).to eq('files/flat/path/correct') }
......
......@@ -342,6 +342,17 @@ describe Member do
expect(source.members.invite.pluck(:invite_email)).to include('user@example.com')
end
end
context 'when called with an unknown user email starting with a number' do
it 'creates an invited member', :aggregate_failures do
email_starting_with_number = "#{user.id}_email@example.com"
described_class.add_user(source, email_starting_with_number, :maintainer)
expect(source.members.invite.pluck(:invite_email)).to include(email_starting_with_number)
expect(source.users.reload).not_to include(user)
end
end
end
context 'when current_user can update member' do
......
......@@ -87,7 +87,7 @@ describe Ci::RetryPipelineService, '#execute' do
it 'creates a new job for report job in this case' do
service.execute(pipeline)
expect(statuses.where(name: 'report 1').first).to be_retried
expect(statuses.find_by(name: 'report 1', status: 'failed')).to be_retried
end
end
......
......@@ -5,7 +5,11 @@ require 'spec_helper'
describe 'projects/tree/_tree_row' do
let(:project) { create(:project, :repository) }
let(:repository) { project.repository }
# rubocop: disable Rails/FindBy
# This is not ActiveRecord where..first
let(:blob_item) { Gitlab::Git::Tree.where(repository, SeedRepo::Commit::ID, 'files/ruby').first }
# rubocop: enable Rails/FindBy
before do
assign(:project, project)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment