Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
061d5e56ab
commit
848ba57883
|
|
@ -24,11 +24,8 @@ static-analysis:
|
|||
extends:
|
||||
- .static-analysis-base
|
||||
- .static-analysis:rules:ee-and-foss
|
||||
- .use-pg12
|
||||
stage: test
|
||||
parallel: 4
|
||||
variables:
|
||||
SETUP_DB: "true"
|
||||
script:
|
||||
- run_timed_command "retry yarn install --frozen-lockfile"
|
||||
- scripts/static-analysis
|
||||
|
|
@ -38,6 +35,17 @@ static-analysis:
|
|||
paths:
|
||||
- tmp/feature_flags/
|
||||
|
||||
static-analysis-with-database:
|
||||
extends:
|
||||
- .static-analysis-base
|
||||
- .static-analysis:rules:ee-and-foss
|
||||
- .use-pg12
|
||||
stage: test
|
||||
script:
|
||||
- bundle exec rake lint:static_verification_with_database
|
||||
variables:
|
||||
SETUP_DB: "true"
|
||||
|
||||
static-analysis as-if-foss:
|
||||
extends:
|
||||
- static-analysis
|
||||
|
|
|
|||
|
|
@ -1,9 +1,4 @@
|
|||
#!/usr/bin/env ruby
|
||||
begin
|
||||
load File.expand_path('../spring', __FILE__)
|
||||
rescue LoadError => e
|
||||
raise unless e.message.include?('spring')
|
||||
end
|
||||
APP_PATH = File.expand_path('../config/application', __dir__)
|
||||
require_relative '../config/boot'
|
||||
require 'rails/commands'
|
||||
|
|
|
|||
5
bin/rake
5
bin/rake
|
|
@ -1,9 +1,4 @@
|
|||
#!/usr/bin/env ruby
|
||||
begin
|
||||
load File.expand_path('../spring', __FILE__)
|
||||
rescue LoadError => e
|
||||
raise unless e.message.include?('spring')
|
||||
end
|
||||
require_relative '../config/boot'
|
||||
require 'rake'
|
||||
Rake.application.run
|
||||
|
|
|
|||
|
|
@ -32,10 +32,10 @@ For a complete overview of these methodologies and GitLab CI/CD,
|
|||
read the [Introduction to CI/CD with GitLab](introduction/index.md).
|
||||
|
||||
<div class="video-fallback">
|
||||
Video demonstration of GitLab CI/CD: <a href="https://www.youtube.com/watch?v=1iXFbchozdY">Demo: CI/CD with GitLab</a>.
|
||||
Video demonstration of continuous integration with GitLab CI/CD: <a href="https://www.youtube.com/watch?v=ljth1Q5oJoo">Continuous Integration with GitLab (overview demo)</a>.
|
||||
</div>
|
||||
<figure class="video-container">
|
||||
<iframe src="https://www.youtube.com/embed/1iXFbchozdY" frameborder="0" allowfullscreen="true"> </iframe>
|
||||
<iframe src="https://www.youtube.com/embed/ljth1Q5oJoo" frameborder="0" allowfullscreen="true"> </iframe>
|
||||
</figure>
|
||||
|
||||
## GitLab CI/CD concepts
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ group: Distribution
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Create a GitLab upgrade plan
|
||||
# Create a GitLab upgrade plan **(FREE SELF)**
|
||||
|
||||
This document serves as a guide to create a strong plan to upgrade a self-managed
|
||||
GitLab instance.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ group: Distribution
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
|
||||
---
|
||||
|
||||
# Zero downtime upgrades
|
||||
# Zero downtime upgrades **(FREE SELF)**
|
||||
|
||||
Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
|
||||
patch version of GitLab without having to take your GitLab instance offline.
|
||||
|
|
@ -428,7 +428,7 @@ sure you remove `/etc/gitlab/skip-auto-reconfigure` and revert
|
|||
setting `gitlab_rails['auto_migrate'] = false` in
|
||||
`/etc/gitlab/gitlab.rb` after you've completed these steps.
|
||||
|
||||
### Use Redis HA (using Sentinel) **(PREMIUM ONLY)**
|
||||
### Use Redis HA (using Sentinel) **(PREMIUM SELF)**
|
||||
|
||||
Package upgrades may involve version updates to the bundled Redis service. On
|
||||
instances using [Redis for scaling](../administration/redis/index.md),
|
||||
|
|
@ -525,7 +525,7 @@ failover is complete, we can go ahead and upgrade the original primary node.
|
|||
Install the package for new version and follow regular package upgrade
|
||||
procedure.
|
||||
|
||||
## Geo deployment **(PREMIUM ONLY)**
|
||||
## Geo deployment **(PREMIUM SELF)**
|
||||
|
||||
The order of steps is important. While following these steps, make
|
||||
sure you follow them in the right order, on the correct node.
|
||||
|
|
@ -645,7 +645,7 @@ sure you remove `/etc/gitlab/skip-auto-reconfigure` and revert
|
|||
setting `gitlab_rails['auto_migrate'] = false` in
|
||||
`/etc/gitlab/gitlab.rb` after you've completed these steps.
|
||||
|
||||
## Multi-node / HA deployment with Geo **(PREMIUM ONLY)**
|
||||
## Multi-node / HA deployment with Geo **(PREMIUM SELF)**
|
||||
|
||||
This section describes the steps required to upgrade a multi-node / HA
|
||||
deployment with Geo. Some steps must be performed on a particular node. This
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ type: reference
|
|||
|
||||
# Custom instance-level project templates **(PREMIUM SELF)**
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6860) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.2.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6860) in GitLab 11.2.
|
||||
|
||||
GitLab administrators can set a group to be the source of project templates that are
|
||||
selectable when a new project is created on the instance. These templates can be selected
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ All Geo sites have the following settings:
|
|||
The site you're currently browsing is indicated with a blue `Current` label, and
|
||||
the **primary** node is listed first as `Primary site`.
|
||||
|
||||
## **Secondary** site settings
|
||||
## Secondary site settings
|
||||
|
||||
**Secondary** sites have a number of additional settings available:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
type: howto
|
||||
---
|
||||
|
||||
# Moderate users
|
||||
# Moderate users **(FREE SELF)**
|
||||
|
||||
GitLab administrators can moderate user access by approving, blocking, banning, or deactivating
|
||||
users.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/329511) in GitLab 13.12.
|
||||
> - Enabled on GitLab.com.
|
||||
> - Recommended for production use.
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations). **(FREE SELF)**
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations).
|
||||
|
||||
There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
|
||||
Refer to this feature's version history for more details.
|
||||
|
|
@ -21,12 +21,12 @@ are created by GitLab developers and run automatically on upgrade. However, such
|
|||
limited in scope to help with migrating some `integer` database columns to `bigint`. This is needed to
|
||||
prevent integer overflow for some tables.
|
||||
|
||||
## Check the status of background migrations **(FREE SELF)**
|
||||
## Check the status of background migrations
|
||||
|
||||
All migrations must have a `Finished` status before you [upgrade GitLab](../../../update/index.md).
|
||||
You can [check the status of existing migrations](../../../update/index.md#checking-for-background-migrations-before-upgrading).
|
||||
|
||||
## Enable or disable batched background migrations **(FREE SELF)**
|
||||
## Enable or disable batched background migrations
|
||||
|
||||
Batched background migrations are under development but ready for production use.
|
||||
It is deployed behind a feature flag that is **enabled by default**.
|
||||
|
|
@ -45,21 +45,21 @@ To disable it:
|
|||
Feature.disable(:execute_batched_migrations_on_schedule)
|
||||
```
|
||||
|
||||
## Automatic batch size optimization **(FREE SELF)**
|
||||
## Automatic batch size optimization
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60133) in GitLab 13.12.
|
||||
> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
|
||||
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/329511) in GitLab 13.12.
|
||||
> - Enabled on GitLab.com.
|
||||
> - Recommended for production use.
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization). **(FREE SELF)**
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization).
|
||||
|
||||
There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
|
||||
Refer to this feature's version history for more details.
|
||||
|
||||
To maximize throughput of batched background migrations (in terms of the number of tuples updated per time unit), batch sizes are automatically adjusted based on how long the previous batches took to complete.
|
||||
|
||||
## Enable or disable automatic batch size optimization **(FREE SELF)**
|
||||
## Enable or disable automatic batch size optimization
|
||||
|
||||
Automatic batch size optimization for batched background migrations is under development but ready for production use.
|
||||
It is deployed behind a feature flag that is **enabled by default**.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ details:
|
|||
|
||||
|
||||
|
||||
## Maximum artifacts size **(FREE SELF)**
|
||||
## Maximum artifacts size
|
||||
|
||||
The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
|
||||
can be set at:
|
||||
|
|
@ -310,7 +310,7 @@ To set the maximum file size:
|
|||
> - [Deployed behind a feature flag](../../feature_flags.md), disabled by default.
|
||||
> - Disabled on GitLab.com.
|
||||
> - Not recommended for production use.
|
||||
> - To use in GitLab self-managed instances, ask a GitLab administrator to enable it. **(FREE SELF)**
|
||||
> - To use in GitLab self-managed instances, ask a GitLab administrator to enable it.
|
||||
|
||||
GitLab administrators can adjust who is allowed to register runners, by showing and hiding areas of the UI.
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ To add additional text to emails:
|
|||
1. Enter your text in the **Additional text** field.
|
||||
1. Select **Save changes**.
|
||||
|
||||
## User deactivation emails **(FREE SELF)**
|
||||
## User deactivation emails
|
||||
|
||||
GitLab sends email notifications to users when their account has been deactivated.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ To can change its value:
|
|||
1. Select **Save changes**.
|
||||
|
||||
For example, if you set a limit of 300, requests using the
|
||||
[Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/raw/master/app/controllers/projects/issues_controller.rb)
|
||||
[Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/issues_controller.rb)
|
||||
action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute.
|
||||
|
||||
When using [epics](../../group/epics/index.md), epic creation will share this rate limit with issues.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ module Gitlab
|
|||
end
|
||||
|
||||
def all_stderr_empty?
|
||||
results.all? { |result| stderr_empty_ignoring_spring(result) }
|
||||
results.all? { |result| result.stderr.empty? }
|
||||
end
|
||||
|
||||
def failed_results
|
||||
|
|
@ -40,22 +40,9 @@ module Gitlab
|
|||
|
||||
def warned_results
|
||||
results.select do |result|
|
||||
result.status.success? && !stderr_empty_ignoring_spring(result)
|
||||
result.status.success? && !result.stderr.empty?
|
||||
end
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
# NOTE: This is sometimes required instead of just calling `result.stderr.empty?`, if we
|
||||
# want to ignore the spring "Running via Spring preloader..." output to STDERR.
|
||||
# The `Spring.quiet=true` method which spring supports doesn't work, because it doesn't
|
||||
# work to make it quiet when using spring binstubs (the STDERR is printed by `bin/spring`
|
||||
# itself when first required, so there's no opportunity to set Spring.quiet=true).
|
||||
# This should probably be opened as a bug against Spring, with a pull request to support a
|
||||
# `SPRING_QUIET` env var as well.
|
||||
def stderr_empty_ignoring_spring(result)
|
||||
result.stderr.empty? || result.stderr =~ /\ARunning via Spring preloader in process [0-9]+\Z/
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -12,6 +12,13 @@ unless Rails.env.production?
|
|||
dev:load
|
||||
] do
|
||||
Gitlab::Utils::Override.verify!
|
||||
end
|
||||
|
||||
desc "GitLab | Lint | Static verification with database"
|
||||
task static_verification_with_database: %w[
|
||||
lint:static_verification_env
|
||||
dev:load
|
||||
] do
|
||||
Gitlab::Utils::DelegatorOverride.verify!
|
||||
end
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue