kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2022-01-07 21:17:37 +00:00
parent 8bac8f55ba
commit f0b862a982
39 changed files with 115 additions and 484 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
app/experiments/new_project_sast_enabled_experiment.rb
View file

@ -15,4 +15,7 @@ class NewProjectSastEnabledExperiment < ApplicationExperiment # rubocop:disable
def unchecked_candidate_behavior
end
def unchecked_free_indicator_behavior
end
end

1
app/models/namespace.rb
View file

@ -43,6 +43,7 @@ class Namespace < ApplicationRecord
has_many :projects, dependent: :destroy # rubocop:disable Cop/ActiveRecordDependent
has_many :project_statistics
has_one :namespace_settings, inverse_of: :namespace, class_name: 'NamespaceSetting', autosave: true
has_one :namespace_route, foreign_key: :namespace_id, autosave: true, inverse_of: :namespace, class_name: 'Route'
has_many :runner_namespaces, inverse_of: :namespace, class_name: 'Ci::RunnerNamespace'
has_many :runners, through: :runner_namespaces, source: :runner, class_name: 'Ci::Runner'

1
app/models/route.rb
View file

@ -5,6 +5,7 @@ class Route < ApplicationRecord
include Gitlab::SQL::Pattern
belongs_to :source, polymorphic: true, inverse_of: :route # rubocop:disable Cop/PolymorphicAssociations
belongs_to :namespace, inverse_of: :namespace_route
validates :source, presence: true
validates :path,

13
db/migrate/20220105121325_add_route_namespace_reference.rb Normal file
View file

@ -0,0 +1,13 @@
# frozen_string_literal: true
class AddRouteNamespaceReference < Gitlab::Database::Migration[1.0]
enable_lock_retries!
def up
add_column :routes, :namespace_id, :bigint unless column_exists?(:routes, :namespace_id)
end
def down
remove_column :routes, :namespace_id if column_exists?(:routes, :namespace_id)
end
end

19
db/migrate/20220107091629_add_route_namespace_index.rb Normal file
View file

@ -0,0 +1,19 @@
# frozen_string_literal: true
class AddRouteNamespaceIndex < Gitlab::Database::Migration[1.0]
disable_ddl_transaction!
INDEX_NAME = 'index_routes_on_namespace_id'
def up
add_concurrent_index :routes, :namespace_id, unique: true, name: INDEX_NAME
add_concurrent_foreign_key :routes, :namespaces, column: :namespace_id, on_delete: :nullify, reverse_lock_order: true
end
def down
with_lock_retries do
remove_foreign_key_if_exists :routes, column: :namespace_id
end
remove_concurrent_index_by_name :routes, INDEX_NAME
end
end

1
db/schema_migrations/20220105121325 Normal file
View file

@ -0,0 +1 @@
27ca3977a7569e98271eeb2bd224be1cfe5452ab3778665325b89bf966e07942

1
db/schema_migrations/20220107091629 Normal file
View file

@ -0,0 +1 @@
ef1a7c5f7b10640a0ddc669528dcdb02fd2525d716562f928578e8902a07a832

8
db/structure.sql
View file

@ -19236,7 +19236,8 @@ CREATE TABLE routes (
path character varying NOT NULL,
created_at timestamp without time zone,
updated_at timestamp without time zone,
name character varying
name character varying,
namespace_id bigint
);
CREATE SEQUENCE routes_id_seq
@ -27396,6 +27397,8 @@ CREATE INDEX index_reviews_on_project_id ON reviews USING btree (project_id);
CREATE INDEX index_route_on_name_trigram ON routes USING gin (name gin_trgm_ops);
CREATE UNIQUE INDEX index_routes_on_namespace_id ON routes USING btree (namespace_id);
CREATE UNIQUE INDEX index_routes_on_path ON routes USING btree (path);
CREATE INDEX index_routes_on_path_text_pattern_ops ON routes USING btree (path varchar_pattern_ops);
@ -29305,6 +29308,9 @@ ALTER TABLE ONLY merge_requests
ALTER TABLE ONLY ci_builds
ADD CONSTRAINT fk_6661f4f0e8 FOREIGN KEY (resource_group_id) REFERENCES ci_resource_groups(id) ON DELETE SET NULL;
ALTER TABLE ONLY routes
ADD CONSTRAINT fk_679ff8213d FOREIGN KEY (namespace_id) REFERENCES namespaces(id) ON DELETE SET NULL;
ALTER TABLE ONLY application_settings
ADD CONSTRAINT fk_693b8795e4 FOREIGN KEY (push_rule_id) REFERENCES push_rules(id) ON DELETE SET NULL;

2
doc/administration/monitoring/github_imports.md
View file

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Monitoring GitHub imports **(FREE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14731) in GitLab 10.2.
The GitHub importer exposes various Prometheus metrics that you can use to
monitor the health and progress of the importer.

2
doc/administration/monitoring/prometheus/pgbouncer_exporter.md
View file

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# PgBouncer exporter **(FREE SELF)**
> Introduced in [Omnibus GitLab 11.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2493).
The [PgBouncer exporter](https://github.com/prometheus-community/pgbouncer_exporter) enables
you to measure various [PgBouncer](https://www.pgbouncer.org/) metrics.

2
doc/administration/monitoring/prometheus/registry_exporter.md
View file

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Registry exporter **(FREE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2884) in GitLab 11.9.
The Registry exporter allows you to measure various Registry metrics.
To enable it:

7
doc/administration/packages/container_registry.md
View file

@ -965,8 +965,6 @@ understand the implications.
### Removing untagged manifests and unreferenced layers
> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3097) in Omnibus GitLab 11.10.
WARNING:
This is a destructive operation.
@ -1341,7 +1339,10 @@ Start with a value between `25000000` (25MB) and `50000000` (50MB).
### Supporting older Docker clients
As of GitLab 11.9, we began shipping version 2.7.1 of the Docker container registry, which disables the schema1 manifest by default. If you are still using older Docker clients (1.9 or older), you may experience an error pushing images. See [omnibus-4145](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4145) for more details.
The Docker container registry shipped with GitLab disables the schema1 manifest
by default. If you are still using older Docker clients (1.9 or older), you may
experience an error pushing images. See
[omnibus-4145](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4145) for more details.
You can add a configuration option for backwards compatibility.

3
doc/api/container_registry.md
View file

@ -6,8 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Container Registry API **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55978) in GitLab 11.8.
> - The use of `CI_JOB_TOKEN` scoped to the current project was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49750) in GitLab 13.12.
> The use of `CI_JOB_TOKEN` scoped to the current project was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49750) in GitLab 13.12.
This is the API documentation of the [GitLab Container Registry](../user/packages/container_registry/index.md).

8
doc/api/packages.md
View file

@ -12,8 +12,6 @@ This is the API documentation of [GitLab Packages](../administration/packages/in
### Within a project
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9259) in GitLab 11.8.
Get a list of project packages. All package types are included in results. When
accessed without authentication, only packages of public projects are returned.
@ -176,8 +174,6 @@ can result in malformed data or broken packages.
## Get a project package
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9667) in GitLab 11.9.
Get a single project package.
```plaintext
@ -258,8 +254,6 @@ The `_links` object contains the following properties:
## List package files
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9305) in GitLab 11.8.
Get a list of package files of a single package.
```plaintext
@ -331,8 +325,6 @@ By default, the `GET` request returns 20 results, because the API is [paginated]
## Delete a project package
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9623) in GitLab 11.9.
Deletes a project package.
```plaintext

8
doc/api/packages/maven.md
View file

@ -22,8 +22,6 @@ for details on which headers and token types are supported.
## Download a package file at the instance-level
> Introduced in GitLab 11.6.
Download a Maven package file:
```plaintext
@ -49,8 +47,6 @@ This writes the downloaded file to `mypkg-1.0-SNAPSHOT.jar` in the current direc
## Download a package file at the group-level
> Introduced in GitLab 11.7.
Download a Maven package file:
```plaintext
@ -76,8 +72,6 @@ This writes the downloaded file to `mypkg-1.0-SNAPSHOT.jar` in the current direc
## Download a package file at the project-level
> Introduced in GitLab 11.3.
Download a Maven package file:
```plaintext
@ -103,8 +97,6 @@ This writes the downloaded file to `mypkg-1.0-SNAPSHOT.jar` in the current direc
## Upload a package file
> Introduced in GitLab 11.3.
Upload a Maven package file:
```plaintext

6
doc/api/packages/npm.md
View file

@ -22,8 +22,6 @@ for details on which headers and token types are supported.
## Download a package
> Introduced in GitLab 11.8.
Downloads the npm package. This URL is provided by the [metadata endpoint](#metadata).
```plaintext
@ -50,8 +48,6 @@ This writes the downloaded file to `@myscope/my-pkg-0.0.1.tgz` in the current di
## Upload a package file
> Introduced in GitLab 11.8.
Upload a package.
```plaintext
@ -153,8 +149,6 @@ The examples in this document all use the project-level prefix.
## Metadata
> Introduced in GitLab 11.8.
Returns the metadata for a given package.
```plaintext

2
doc/api/packages/pypi.md
View file

@ -166,8 +166,6 @@ This writes the downloaded file to `simple.html` in the current directory.
## Upload a package
> Introduced in GitLab 11.3.
Upload a PyPI package:
```plaintext

10
doc/ci/pipelines/settings.md
View file

@ -23,10 +23,6 @@ For public and internal projects, you can change who can see your:
- Job artifacts
- [Pipeline security dashboard](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline)
However:
- Job output logs and artifacts are [never visible for Guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
To change the visibility of your pipelines and related features:
1. On the top bar, select **Menu > Projects** and find your project.
@ -41,8 +37,10 @@ To change the visibility of your pipelines and related features:
When it is cleared:
- For **public** projects, pipelines are visible to everyone. Related features are visible
only to project members (Reporter or higher).
- For **public** projects, job logs, job artifacts, the pipeline security dashboard,
and the **CI/CD** menu items are visible only to project members (Reporter or higher).
Other users, including guest users, can only view the status of pipelines and jobs, and only
when viewing merge requests or commits.
- For **internal** projects, pipelines are visible to all logged in users except [external users](../../user/permissions.md#external-users).
Related features are visible only to project members (Reporter or higher).
- For **private** projects, pipelines and related features are visible to project members (Reporter or higher) only.

97
doc/development/avoiding_downtime_in_migrations.md
View file

@ -228,100 +228,9 @@ can take a very long time to complete, preventing a deployment from proceeding.
They can also produce a lot of pressure on the database due to it rapidly
updating many rows in sequence.
To reduce database pressure you should instead use
`change_column_type_using_background_migration` or `rename_column_using_background_migration`
when migrating a column in a large table (for example, `issues`). These methods work
similarly to the concurrent counterparts but uses background migration to spread
the work / load over a longer time period, without slowing down deployments.
For example, to change the column type using a background migration:
```ruby
class ExampleMigration < Gitlab::Database::Migration[1.0]
disable_ddl_transaction!
class Issue < ActiveRecord::Base
self.table_name = 'issues'
include EachBatch
def self.to_migrate
where('closed_at IS NOT NULL')
end
end
def up
change_column_type_using_background_migration(
Issue.to_migrate,
:closed_at,
:datetime_with_timezone
)
end
def down
change_column_type_using_background_migration(
Issue.to_migrate,
:closed_at,
:datetime
)
end
end
```
This would change the type of `issues.closed_at` to `timestamp with time zone`.
Keep in mind that the relation passed to
`change_column_type_using_background_migration` _must_ include `EachBatch`,
otherwise it will raise a `TypeError`.
This migration then needs to be followed in a separate release (_not_ a patch
release) by a cleanup migration, which should steal from the queue and handle
any remaining rows. For example:
```ruby
class MigrateRemainingIssuesClosedAt < Gitlab::Database::Migration[1.0]
disable_ddl_transaction!
class Issue < ActiveRecord::Base
self.table_name = 'issues'
include EachBatch
end
def up
Gitlab::BackgroundMigration.steal('CopyColumn')
Gitlab::BackgroundMigration.steal('CleanupConcurrentTypeChange')
migrate_remaining_rows if migrate_column_type?
end
def down
# Previous migrations already revert the changes made here.
end
def migrate_remaining_rows
Issue.where('closed_at_for_type_change IS NULL AND closed_at IS NOT NULL').each_batch do |batch|
batch.update_all('closed_at_for_type_change = closed_at')
end
cleanup_concurrent_column_type_change(:issues, :closed_at)
end
def migrate_column_type?
# Some environments may have already executed the previous version of this
# migration, thus we don't need to migrate those environments again.
column_for('issues', 'closed_at').type == :datetime # rubocop:disable Migration/Datetime
end
end
```
The same applies to `rename_column_using_background_migration`:
1. Create a migration using the helper, which will schedule background
migrations to spread the writes over a longer period of time.
1. In the next monthly release, create a clean-up migration to steal from the
Sidekiq queues, migrate any missing rows, and cleanup the rename. This
migration should skip the steps after stealing from the Sidekiq queues if the
column has already been renamed.
To reduce database pressure you should instead use a background migration
when migrating a column in a large table (for example, `issues`). This will
spread the work / load over a longer time period, without slowing down deployments.
For more information, see [the documentation on cleaning up background
migrations](background_migrations.md#cleaning-up).

11
doc/development/database/loose_foreign_keys.md
View file

@ -161,6 +161,17 @@ it_behaves_like 'it has loose foreign keys' do
end
```
**After** [removing a foreign key](#remove-the-foreign-key),
use the "`cleanup by a loose foreign key`" shared example to test a child record's deletion or nullification
via the added loose foreign key:
```ruby
it_behaves_like 'cleanup by a loose foreign key' do
let!(:model) { create(:ci_pipeline, user: create(:user)) }
let!(:parent) { model.user }
end
```
## Caveats of loose foreign keys
### Record creation

8
doc/development/documentation/styleguide/word_list.md
View file

@ -202,11 +202,19 @@ Use **confirmation dialog** to describe the dialog box that asks you to confirm
- On the confirmation dialog, select **OK**.
## Container Registry
Use title case for the GitLab Container Registry.
## currently
Do not use **currently** when talking about the product or its features. The documentation describes the product as it is today.
([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml))
## Dependency Proxy
Use title case for the GitLab Dependency Proxy.
## deploy board
Use lowercase for **deploy board**.

2
doc/operations/error_tracking.md
View file

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Error Tracking **(FREE)**
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/169) in GitLab 11.8.
Error Tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased.
## How error tracking works

2
doc/operations/incident_management/incidents.md
View file

@ -47,8 +47,6 @@ To create an incident from the Issues List:
### Create incidents automatically **(ULTIMATE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4925) in GitLab 11.11.
With at least the Maintainer [role](../../user/permissions.md), you can enable
GitLab to create incident automatically whenever an alert is triggered:

5
doc/operations/metrics/alerts.md
View file

@ -19,8 +19,7 @@ Alerts are not currently supported for [Prometheus cluster integrations](../../u
## External Prometheus instances
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9258) in GitLab Ultimate 11.8.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to GitLab Free in 12.10.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to GitLab Free in 12.10.
For manually configured Prometheus servers, GitLab provides a notify endpoint for
use with Prometheus webhooks. If you have manual configuration enabled, an
@ -61,8 +60,6 @@ Prometheus server to use the
## Trigger actions from alerts **(ULTIMATE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4925) in GitLab 11.11.
Alerts can be used to trigger actions, like opening an issue automatically
(disabled by default since `13.1`). To configure the actions:

3
doc/operations/tracing.md
View file

@ -6,8 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Tracing **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7903) in GitLab 11.5.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42645) from GitLab Ultimate to GitLab Free in 13.5.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42645) from GitLab Ultimate to GitLab Free in 13.5.
Tracing provides insight into the performance and health of a deployed application, tracking each
function or microservice that handles a given request. Tracing makes it easy to understand the

7
doc/user/packages/container_registry/index.md
View file

@ -6,13 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# GitLab Container Registry **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4040) in GitLab 8.8.
> - Docker Registry manifest `v1` support was added in GitLab 8.9 to support Docker
> versions earlier than 1.10.
> - Starting in GitLab 8.12, if you have [two-factor authentication](../../profile/account/two_factor_authentication.md) enabled in your account, you need
> to pass a [personal access token](../../profile/personal_access_tokens.md) instead of your password to
> sign in to the Container Registry.
> - Support for multiple level image names was added in GitLab 9.1.
> - The group-level Container Registry was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23315) in GitLab 12.10.
> - Searching by image repository name was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31322) in GitLab 13.0.

1
doc/user/packages/dependency_proxy/index.md
View file

@ -6,7 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Dependency Proxy **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7934) in GitLab 11.11.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/273655) from GitLab Premium to GitLab Free in 13.6.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11582) support for private groups in GitLab 13.7.
> - Anonymous access to images in public groups is no longer available starting in GitLab 13.7.

9
doc/user/packages/maven_repository/index.md
View file

@ -6,8 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Maven packages in the Package Repository **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5811) in GitLab 11.3.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
Publish [Maven](https://maven.apache.org) artifacts in your project's Package Registry.
Then, install the packages whenever you need to use them as a dependency.
@ -418,8 +417,7 @@ repositories {
### Group-level Maven endpoint
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8798) in GitLab 11.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
If you rely on many packages, it might be inefficient to include the `repository` section
with a unique URL for each package. Instead, you can use the group-level endpoint for
@ -476,8 +474,7 @@ repositories {
### Instance-level Maven endpoint
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8274) in GitLab 11.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
If you rely on many packages, it might be inefficient to include the `repository` section
with a unique URL for each package. Instead, you can use the instance-level endpoint for

5
doc/user/packages/npm_registry/index.md
View file

@ -6,8 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# npm packages in the Package Registry **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5934) in GitLab 11.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) from GitLab Premium to GitLab Free in 13.3.
Publish npm packages in your project's Package Registry. Then install the
packages whenever you need to use them as a dependency.
@ -579,8 +578,6 @@ If you get this error, ensure that:
by default, it's possible to [disable it](../package_registry/#disable-the-package-registry).
- Your token is not expired and has appropriate permissions.
- A package with the same name or version doesn't already exist within the given scope.
- Your NPM package name does not contain a dot `.`. This is a [known issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/10248)
in GitLab 11.9 and earlier.
- The scoped packages URL includes a trailing slash:
- Correct: `//gitlab.example.com/api/v4/packages/npm/`
- Incorrect: `//gitlab.example.com/api/v4/packages/npm`

23
doc/user/project/code_owners.md
View file

@ -280,3 +280,26 @@ model/db @database
[DOCUMENTATION]
README.md @docs
```
## Troubleshooting
### Approvals shown as optional
A Code Owner approval rule is optional if these conditions are not met:
- The user or group are not a member of the project or parent group.
- [Code Owner approval on a protected branch](protected_branches.md#require-code-owner-approval-on-a-protected-branch) has not been set up.
- The section is [marked as optional](#make-a-code-owners-section-optional).
### Approvals do not show
Code Owner approval rules only update when the merge request is created.
If you update the `CODEOWNERS` file, close the merge request and create a new one.
### User not shown as possible approver
A user might not show as an approver on the Code Owner merge request approval rules.
This result occurs when a rule prevents the specific user from approving the merge request.
Check the project
[merge request approval setting](merge_requests/approvals/settings.md#edit-merge-request-approval-settings).

2
doc/user/project/integrations/prometheus_library/nginx_ingress.md
View file

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Monitoring NGINX Ingress Controller **(FREE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22133) in GitLab 11.7.
GitLab has support for automatically detecting and monitoring the Kubernetes NGINX Ingress controller. This is provided by leveraging the built-in Prometheus metrics included with Kubernetes NGINX Ingress controller [version 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160) onward.
NOTE:

180
lib/gitlab/database/migration_helpers.rb
View file

@ -778,186 +778,6 @@ module Gitlab
install_rename_triggers(table, old, new)
end
# Changes the column type of a table using a background migration.
#
# Because this method uses a background migration it's more suitable for
# large tables. For small tables it's better to use
# `change_column_type_concurrently` since it can complete its work in a
# much shorter amount of time and doesn't rely on Sidekiq.
#
# Example usage:
#
# class Issue < ActiveRecord::Base
# self.table_name = 'issues'
#
# include EachBatch
#
# def self.to_migrate
# where('closed_at IS NOT NULL')
# end
# end
#
# change_column_type_using_background_migration(
# Issue.to_migrate,
# :closed_at,
# :datetime_with_timezone
# )
#
# Reverting a migration like this is done exactly the same way, just with
# a different type to migrate to (e.g. `:datetime` in the above example).
#
# relation - An ActiveRecord relation to use for scheduling jobs and
# figuring out what table we're modifying. This relation _must_
# have the EachBatch module included.
#
# column - The name of the column for which the type will be changed.
#
# new_type - The new type of the column.
#
# batch_size - The number of rows to schedule in a single background
# migration.
#
# interval - The time interval between every background migration.
def change_column_type_using_background_migration(
relation,
column,
new_type,
batch_size: 10_000,
interval: 10.minutes
)
unless relation.model < EachBatch
raise TypeError, 'The relation must include the EachBatch module'
end
temp_column = "#{column}_for_type_change"
table = relation.table_name
max_index = 0
add_column(table, temp_column, new_type)
install_rename_triggers(table, column, temp_column)
# Schedule the jobs that will copy the data from the old column to the
# new one. Rows with NULL values in our source column are skipped since
# the target column is already NULL at this point.
relation.where.not(column => nil).each_batch(of: batch_size) do |batch, index|
start_id, end_id = batch.pluck('MIN(id), MAX(id)').first
max_index = index
migrate_in(
index * interval,
'CopyColumn',
[table, column, temp_column, start_id, end_id]
)
end
# Schedule the renaming of the column to happen (initially) 1 hour after
# the last batch finished.
migrate_in(
(max_index * interval) + 1.hour,
'CleanupConcurrentTypeChange',
[table, column, temp_column]
)
if perform_background_migration_inline?
# To ensure the schema is up to date immediately we perform the
# migration inline in dev / test environments.
Gitlab::BackgroundMigration.steal('CopyColumn')
Gitlab::BackgroundMigration.steal('CleanupConcurrentTypeChange')
end
end
# Renames a column using a background migration.
#
# Because this method uses a background migration it's more suitable for
# large tables. For small tables it's better to use
# `rename_column_concurrently` since it can complete its work in a much
# shorter amount of time and doesn't rely on Sidekiq.
#
# Example usage:
#
# rename_column_using_background_migration(
# :users,
# :feed_token,
# :rss_token
# )
#
# table - The name of the database table containing the column.
#
# old - The old column name.
#
# new - The new column name.
#
# type - The type of the new column. If no type is given the old column's
# type is used.
#
# batch_size - The number of rows to schedule in a single background
# migration.
#
# interval - The time interval between every background migration.
def rename_column_using_background_migration(
table,
old_column,
new_column,
type: nil,
batch_size: 10_000,
interval: 10.minutes
)
check_trigger_permissions!(table)
old_col = column_for(table, old_column)
new_type = type || old_col.type
max_index = 0
add_column(table, new_column, new_type,
limit: old_col.limit,
precision: old_col.precision,
scale: old_col.scale)
# We set the default value _after_ adding the column so we don't end up
# updating any existing data with the default value. This isn't
# necessary since we copy over old values further down.
change_column_default(table, new_column, old_col.default) if old_col.default
install_rename_triggers(table, old_column, new_column)
model = Class.new(ActiveRecord::Base) do
self.table_name = table
include ::EachBatch
end
# Schedule the jobs that will copy the data from the old column to the
# new one. Rows with NULL values in our source column are skipped since
# the target column is already NULL at this point.
model.where.not(old_column => nil).each_batch(of: batch_size) do |batch, index|
start_id, end_id = batch.pluck('MIN(id), MAX(id)').first
max_index = index
migrate_in(
index * interval,
'CopyColumn',
[table, old_column, new_column, start_id, end_id]
)
end
# Schedule the renaming of the column to happen (initially) 1 hour after
# the last batch finished.
migrate_in(
(max_index * interval) + 1.hour,
'CleanupConcurrentRename',
[table, old_column, new_column]
)
if perform_background_migration_inline?
# To ensure the schema is up to date immediately we perform the
# migration inline in dev / test environments.
Gitlab::BackgroundMigration.steal('CopyColumn')
Gitlab::BackgroundMigration.steal('CleanupConcurrentRename')
end
end
def convert_to_bigint_column(column)
"#{column}_convert_to_bigint"
end

4
lib/gitlab/database/migrations/background_migration_helpers.rb
View file

@ -152,10 +152,6 @@ module Gitlab
delete_job_tracking(class_name, status: delete_tracking_jobs) if delete_tracking_jobs
end
def perform_background_migration_inline?
Rails.env.test? || Rails.env.development?
end
def migrate_in(*args, coordinator: coordinator_for_tracking_database)
with_migration_context do
coordinator.perform_in(*args)

7
spec/experiments/new_project_sast_enabled_experiment_spec.rb
View file

@ -4,7 +4,12 @@ require 'spec_helper'
RSpec.describe NewProjectSastEnabledExperiment do
it "defines the expected behaviors and variants" do
expect(subject.behaviors.keys).to match_array(%w[control candidate free_indicator unchecked_candidate])
expect(subject.variant_names).to match_array([
:candidate,
:free_indicator,
:unchecked_candidate,
:unchecked_free_indicator
])
end
it "publishes to the database" do

112
spec/lib/gitlab/database/migration_helpers_spec.rb
View file

@ -1752,116 +1752,6 @@ RSpec.describe Gitlab::Database::MigrationHelpers do
end
end
describe '#change_column_type_using_background_migration' do
let!(:issue) { create(:issue, :closed, closed_at: Time.zone.now) }
let(:issue_model) do
Class.new(ActiveRecord::Base) do
self.table_name = 'issues'
include EachBatch
end
end
it 'changes the type of a column using a background migration' do
expect(model)
.to receive(:add_column)
.with('issues', 'closed_at_for_type_change', :datetime_with_timezone)
expect(model)
.to receive(:install_rename_triggers)
.with('issues', :closed_at, 'closed_at_for_type_change')
expect(BackgroundMigrationWorker)
.to receive(:perform_in)
.ordered
.with(
10.minutes,
'CopyColumn',
['issues', :closed_at, 'closed_at_for_type_change', issue.id, issue.id]
)
expect(BackgroundMigrationWorker)
.to receive(:perform_in)
.ordered
.with(
1.hour + 10.minutes,
'CleanupConcurrentTypeChange',
['issues', :closed_at, 'closed_at_for_type_change']
)
expect(Gitlab::BackgroundMigration)
.to receive(:steal)
.ordered
.with('CopyColumn')
expect(Gitlab::BackgroundMigration)
.to receive(:steal)
.ordered
.with('CleanupConcurrentTypeChange')
model.change_column_type_using_background_migration(
issue_model.all,
:closed_at,
:datetime_with_timezone
)
end
end
describe '#rename_column_using_background_migration' do
let!(:issue) { create(:issue, :closed, closed_at: Time.zone.now) }
it 'renames a column using a background migration' do
expect(model)
.to receive(:add_column)
.with(
'issues',
:closed_at_timestamp,
:datetime_with_timezone,
limit: anything,
precision: anything,
scale: anything
)
expect(model)
.to receive(:install_rename_triggers)
.with('issues', :closed_at, :closed_at_timestamp)
expect(BackgroundMigrationWorker)
.to receive(:perform_in)
.ordered
.with(
10.minutes,
'CopyColumn',
['issues', :closed_at, :closed_at_timestamp, issue.id, issue.id]
)
expect(BackgroundMigrationWorker)
.to receive(:perform_in)
.ordered
.with(
1.hour + 10.minutes,
'CleanupConcurrentRename',
['issues', :closed_at, :closed_at_timestamp]
)
expect(Gitlab::BackgroundMigration)
.to receive(:steal)
.ordered
.with('CopyColumn')
expect(Gitlab::BackgroundMigration)
.to receive(:steal)
.ordered
.with('CleanupConcurrentRename')
model.rename_column_using_background_migration(
'issues',
:closed_at,
:closed_at_timestamp
)
end
end
describe '#convert_to_bigint_column' do
it 'returns the name of the temporary column used to convert to bigint' do
expect(model.convert_to_bigint_column(:id)).to eq('id_convert_to_bigint')
@ -2065,8 +1955,6 @@ RSpec.describe Gitlab::Database::MigrationHelpers do
t.integer :other_id
t.timestamps
end
allow(model).to receive(:perform_background_migration_inline?).and_return(false)
end
context 'when the target table does not exist' do

20
spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb
View file

@ -438,26 +438,6 @@ RSpec.describe Gitlab::Database::Migrations::BackgroundMigrationHelpers do
it_behaves_like 'helpers that enqueue background migrations', BackgroundMigrationWorker, 'main'
end
describe '#perform_background_migration_inline?' do
it 'returns true in a test environment' do
stub_rails_env('test')
expect(model.perform_background_migration_inline?).to eq(true)
end
it 'returns true in a development environment' do
stub_rails_env('development')
expect(model.perform_background_migration_inline?).to eq(true)
end
it 'returns false in a production environment' do
stub_rails_env('production')
expect(model.perform_background_migration_inline?).to eq(false)
end
end
describe '#delete_job_tracking' do
let!(:job_class_name) { 'TestJob' }

1
spec/models/namespace_spec.rb
View file

@ -28,6 +28,7 @@ RSpec.describe Namespace do
it { is_expected.to have_one :onboarding_progress }
it { is_expected.to have_one :admin_note }
it { is_expected.to have_many :pending_builds }
it { is_expected.to have_one :namespace_route }
describe '#children' do
let_it_be(:group) { create(:group) }

1
spec/models/route_spec.rb
View file

@ -8,6 +8,7 @@ RSpec.describe Route do
describe 'relationships' do
it { is_expected.to belong_to(:source) }
it { is_expected.to belong_to(:namespace) }
end
describe 'validations' do

2
spec/support/shared_examples/loose_foreign_keys/have_loose_foreign_key.rb
View file

@ -59,7 +59,7 @@ RSpec.shared_examples 'cleanup by a loose foreign key' do
model.class.find_by(primary_key => model.public_send(primary_key))
end
it 'deletes the model' do
it 'cleans up (delete or nullify) the model' do
parent.delete
expect(find_model).to be_present