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

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-02-11 09:09:18 +00:00
parent 62d57690bc
commit 7240fb1a06
54 changed files with 1163 additions and 817 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Gemfile
View File

@ -293,7 +293,7 @@ gem 'gon', '~> 6.2'
gem 'request_store', '~> 1.5'
gem 'base32', '~> 0.3.0'
gem "gitlab-license", "~> 1.0"
gem "gitlab-license", "~> 1.3"
# Protect against bruteforcing
gem 'rack-attack', '~> 6.3.0'

4
Gemfile.lock
View File

@ -443,7 +443,7 @@ GEM
jaeger-client (~> 1.1)
opentracing (~> 0.4)
redis (> 3.0.0, < 5.0.0)
gitlab-license (1.0.0)
gitlab-license (1.3.0)
gitlab-mail_room (0.0.8)
gitlab-markup (1.7.1)
gitlab-net-dns (0.9.1)
@ -1374,7 +1374,7 @@ DEPENDENCIES
gitlab-experiment (~> 0.4.9)
gitlab-fog-azure-rm (~> 1.0)
gitlab-labkit (= 0.14.0)
gitlab-license (~> 1.0)
gitlab-license (~> 1.3)
gitlab-mail_room (~> 0.0.8)
gitlab-markup (~> 1.7.1)
gitlab-net-dns (~> 0.9.1)

2
app/assets/javascripts/lib/utils/common_utils.js
View File

@ -123,7 +123,7 @@ export const handleLocationHash = () => {
}
if (isInIssuePage()) {
adjustment -= fixedIssuableTitle.offsetHeight;
adjustment -= fixedIssuableTitle?.offsetHeight;
}
if (isInMRPage()) {

24
app/assets/javascripts/pages/projects/merge_requests/edit/check_form_state.js Normal file
View File

@ -0,0 +1,24 @@
import { serializeForm } from '~/lib/utils/forms';
const findForm = () => document.querySelector('.merge-request-form');
const serializeFormData = () => JSON.stringify(serializeForm(findForm()));
export default () => {
const oldFormData = serializeFormData();
const compareFormData = (e) => {
const newFormData = serializeFormData();
if (oldFormData !== newFormData) {
e.preventDefault();
// eslint-disable-next-line no-param-reassign
e.returnValue = ''; // Chrome requires returnValue to be set
}
};
window.addEventListener('beforeunload', compareFormData);
findForm().addEventListener('submit', () =>
window.removeEventListener('beforeunload', compareFormData),
);
};

6
app/assets/javascripts/pages/projects/merge_requests/edit/index.js
View File

@ -1,3 +1,7 @@
import initMergeRequest from '~/pages/projects/merge_requests/init_merge_request';
import initCheckFormState from './check_form_state';
document.addEventListener('DOMContentLoaded', initMergeRequest);
document.addEventListener('DOMContentLoaded', () => {
initMergeRequest();
initCheckFormState();
});

6
app/assets/javascripts/pages/projects/releases/edit/index.js
View File

@ -1,7 +1,5 @@
import ZenMode from '~/zen_mode';
import initEditRelease from '~/releases/mount_edit';
document.addEventListener('DOMContentLoaded', () => {
new ZenMode(); // eslint-disable-line no-new
initEditRelease();
});
new ZenMode(); // eslint-disable-line no-new
initEditRelease();

6
app/assets/javascripts/pages/projects/releases/new/index.js
View File

@ -1,7 +1,5 @@
import ZenMode from '~/zen_mode';
import initNewRelease from '~/releases/mount_new';
document.addEventListener('DOMContentLoaded', () => {
new ZenMode(); // eslint-disable-line no-new
initNewRelease();
});
new ZenMode(); // eslint-disable-line no-new
initNewRelease();

30
app/assets/javascripts/terraform/components/states_table.vue
View File

@ -1,5 +1,14 @@
<script>
import { GlAlert, GlBadge, GlIcon, GlLink, GlSprintf, GlTable, GlTooltip } from '@gitlab/ui';
import {
GlAlert,
GlBadge,
GlIcon,
GlLink,
GlLoadingIcon,
GlSprintf,
GlTable,
GlTooltip,
} from '@gitlab/ui';
import { s__ } from '~/locale';
import { getIdFromGraphQLId } from '~/graphql_shared/utils';
import CiBadge from '~/vue_shared/components/ci_badge_link.vue';
@ -14,6 +23,7 @@ export default {
GlBadge,
GlIcon,
GlLink,
GlLoadingIcon,
GlSprintf,
GlTable,
GlTooltip,
@ -67,15 +77,20 @@ export default {
jobStatus: s__('Terraform|Job status'),
locked: s__('Terraform|Locked'),
lockedByUser: s__('Terraform|Locked by %{user} %{timeAgo}'),
lockingState: s__('Terraform|Locking state'),
name: s__('Terraform|Name'),
pipeline: s__('Terraform|Pipeline'),
unknownUser: s__('Terraform|Unknown User'),
unlockingState: s__('Terraform|Unlocking state'),
updatedUser: s__('Terraform|%{user} updated %{timeAgo}'),
},
methods: {
createdByUserName(item) {
return item.latestVersion?.createdByUser?.name;
},
loadingLockText(item) {
return item.lockedAt ? this.$options.i18n.unlockingState : this.$options.i18n.lockingState;
},
lockedByUserName(item) {
return item.lockedByUser?.name || this.$options.i18n.unknownUser;
},
@ -119,7 +134,18 @@ export default {
{{ item.name }}
</p>
<div v-if="item.lockedAt" :id="`terraformLockedBadgeContainer${item.name}`" class="gl-mx-2">
<div v-if="item.loadingLock" class="gl-mx-3">
<p class="gl-display-flex gl-justify-content-start gl-align-items-baseline gl-m-0">
<gl-loading-icon class="gl-pr-1" />
{{ loadingLockText(item) }}
</p>
</div>
<div
v-else-if="item.lockedAt"
:id="`terraformLockedBadgeContainer${item.name}`"
class="gl-mx-3"
>
<gl-badge :id="`terraformLockedBadge${item.name}`">
<gl-icon name="lock" />
{{ $options.i18n.locked }}

36
app/assets/javascripts/terraform/components/states_table_actions.vue
View File

@ -64,6 +64,9 @@ export default {
disableModalSubmit() {
return this.removeConfirmText !== this.state.name;
},
loading() {
return this.state.loadingLock || this.state.loadingRemove;
},
primaryModalProps() {
return {
text: this.$options.i18n.modalRemove,
@ -77,9 +80,23 @@ export default {
this.removeConfirmText = '';
},
lock() {
this.updateStateCache({
_showDetails: false,
errorMessages: [],
loadingLock: true,
loadingRemove: false,
});
this.stateActionMutation(lockState);
},
unlock() {
this.updateStateCache({
_showDetails: false,
errorMessages: [],
loadingLock: true,
loadingRemove: false,
});
this.stateActionMutation(unlockState);
},
updateStateCache(newData) {
@ -96,18 +113,20 @@ export default {
remove() {
if (!this.disableModalSubmit) {
this.hideModal();
this.updateStateCache({
_showDetails: false,
errorMessages: [],
loadingLock: false,
loadingRemove: true,
});
this.stateActionMutation(removeState);
}
},
stateActionMutation(mutation) {
let errorMessages = [];
this.updateStateCache({
_showDetails: false,
errorMessages,
loadingActions: true,
});
this.$apollo
.mutate({
mutation,
@ -132,7 +151,8 @@ export default {
this.updateStateCache({
_showDetails: Boolean(errorMessages.length),
errorMessages,
loadingActions: false,
loadingLock: false,
loadingRemove: false,
});
});
},
@ -146,7 +166,7 @@ export default {
icon="ellipsis_v"
right
:data-testid="`terraform-state-actions-${state.name}`"
:disabled="state.loadingActions"
:disabled="loading"
toggle-class="gl-px-3! gl-shadow-none!"
>
<template #button-content>

3
app/assets/javascripts/terraform/graphql/fragments/state.fragment.graphql
View File

@ -4,7 +4,8 @@
fragment State on TerraformState {
_showDetails @client
errorMessages @client
loadingActions @client
loadingLock @client
loadingRemove @client
id
name

10
app/assets/javascripts/terraform/graphql/resolvers.js
View File

@ -9,8 +9,11 @@ export default {
errorMessages: (state) => {
return state.errorMessages || [];
},
loadingActions: (state) => {
return state.loadingActions || false;
loadingLock: (state) => {
return state.loadingLock || false;
},
loadingRemove: (state) => {
return state.loadingRemove || false;
},
},
Mutation: {
@ -32,7 +35,8 @@ export default {
// eslint-disable-next-line no-underscore-dangle
_showDetails: terraformState._showDetails,
errorMessages: terraformState.errorMessages,
loadingActions: terraformState.loadingActions,
loadingLock: terraformState.loadingLock,
loadingRemove: terraformState.loadingRemove,
},
});
}

4
app/controllers/groups/boards_controller.rb
View File

@ -15,9 +15,9 @@ class Groups::BoardsController < Groups::ApplicationController
private
def assign_endpoint_vars
@boards_endpoint = group_boards_url(group)
@boards_endpoint = group_boards_path(group)
@namespace_path = group.to_param
@labels_endpoint = group_labels_url(group)
@labels_endpoint = group_labels_path(group)
end
def authorize_read_board!

33
app/services/concerns/integrations/project_test_data.rb
View File

@ -8,6 +8,10 @@ module Integrations
Gitlab::DataBuilder::Push.build_sample(project, current_user)
end
def use_newest_record?
Feature.enabled?(:integrations_test_webhook_reorder, project)
end
def note_events_data
note = NotesFinder.new(current_user, project: project, target: project).execute.reorder(nil).last # rubocop: disable CodeReuse/ActiveRecord
@ -33,14 +37,24 @@ module Integrations
end
def job_events_data
build = project.builds.first
build = if use_newest_record?
Ci::JobsFinder.new(current_user: current_user, project: project).execute.first
else
project.builds.first
end
return { error: s_('TestHooks|Ensure the project has CI jobs.') } unless build.present?
Gitlab::DataBuilder::Build.build(build)
end
def pipeline_events_data
pipeline = project.ci_pipelines.newest_first.first
pipeline = if use_newest_record?
Ci::PipelinesFinder.new(project, current_user, order_by: 'id', sort: 'desc').execute.first
else
project.ci_pipelines.newest_first.first
end
return { error: s_('TestHooks|Ensure the project has CI pipelines.') } unless pipeline.present?
Gitlab::DataBuilder::Pipeline.build(pipeline)
@ -48,6 +62,7 @@ module Integrations
def wiki_page_events_data
page = project.wiki.list_pages(limit: 1).first
if !project.wiki_enabled? || page.blank?
return { error: s_('TestHooks|Ensure the wiki is enabled and has pages.') }
end
@ -56,14 +71,24 @@ module Integrations
end
def deployment_events_data
deployment = project.deployments.first
deployment = if use_newest_record?
DeploymentsFinder.new(project: project, order_by: 'created_at', sort: 'desc').execute.first
else
project.deployments.first
end
return { error: s_('TestHooks|Ensure the project has deployments.') } unless deployment.present?
Gitlab::DataBuilder::Deployment.build(deployment)
end
def releases_events_data
release = project.releases.first
release = if use_newest_record?
ReleasesFinder.new(project, current_user, order_by: :created_at, sort: :desc).execute.first
else
project.releases.first
end
return { error: s_('TestHooks|Ensure the project has releases.') } unless release.present?
release.to_hook_data('create')

11
app/services/test_hooks/system_service.rb
View File

@ -6,6 +6,10 @@ module TestHooks
private
def use_newest_record?
Feature.enabled?(:integrations_test_webhook_reorder)
end
def data
strong_memoize(:data) do
case trigger
@ -20,7 +24,12 @@ module TestHooks
end
def merge_requests_events_data
merge_request = MergeRequest.of_projects(current_user.projects.select(:id)).first
merge_request = if use_newest_record?
MergeRequest.of_projects(current_user.projects.select(:id)).last
else
MergeRequest.of_projects(current_user.projects.select(:id)).first
end
return { error: s_('TestHooks|Ensure one of your projects has merge requests.') } unless merge_request.present?
merge_request.to_hook_data(current_user)

2
app/views/projects/issues/import_csv/_button.html.haml
View File

@ -2,7 +2,7 @@
- can_edit = can?(current_user, :admin_project, @project)
.dropdown.btn-group
%button.btn.gl-button.btn-default.rounded-right.text-center{ class: ('has-tooltip' if type == :icon), title: (_('Import issues') if type == :icon),
%button.btn.gl-button.rounded-right.btn-default.btn-icon.text-center{ class: ('has-tooltip' if type == :icon), title: (_('Import issues') if type == :icon),
data: { toggle: 'dropdown', qa_selector: 'import_issues_button' }, 'aria-label' => _('Import issues'), 'aria-haspopup' => 'true', 'aria-expanded' => 'false' }
- if type == :icon
= sprite_icon('import')

4
app/views/shared/issuable/_feed_buttons.html.haml
View File

@ -1,4 +1,4 @@
= link_to safe_params.merge(rss_url_options), class: 'btn gl-button btn-default has-tooltip', data: { container: 'body', testid: 'rss-feed-link' }, title: _('Subscribe to RSS feed') do
= link_to safe_params.merge(rss_url_options), class: 'btn gl-button btn-default btn-icon has-tooltip', data: { container: 'body', testid: 'rss-feed-link' }, title: _('Subscribe to RSS feed') do
= sprite_icon('rss', css_class: 'qa-rss-icon')
= link_to safe_params.merge(calendar_url_options), class: 'btn gl-button btn-default has-tooltip', data: { container: 'body' }, title: _('Subscribe to calendar') do
= link_to safe_params.merge(calendar_url_options), class: 'btn gl-button btn-default btn-icon has-tooltip', data: { container: 'body' }, title: _('Subscribe to calendar') do
= sprite_icon('calendar')

2
app/views/shared/issuable/csv_export/_button.html.haml
View File

@ -1,4 +1,4 @@
- if current_user
%button.csv_download_link.btn.gl-button.btn-default.has-tooltip{ title: _('Export as CSV'),
%button.csv_download_link.btn.gl-button.btn-default.btn-icon.has-tooltip{ title: _('Export as CSV'),
data: { toggle: 'modal', target: ".#{issuable_type}-export-modal", qa_selector: 'export_as_csv_button' } }
= sprite_icon('export')

5
changelogs/unreleased/290622-display-warning-mr-edit.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Display unload warning if MR edit changed
merge_request: 53438
author:
type: added

5
changelogs/unreleased/292713-tf-lock-loading.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Add loading display to Terraform lock action
merge_request: 53475
author:
type: changed

5
changelogs/unreleased/btn-icon-issues.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Add btn-icon class for icon only buttons in issues header
merge_request: 53562
author: Yogi (@yo)
type: other

8
config/feature_flags/development/integrations_test_webhook_reorder.yml Normal file
View File

@ -0,0 +1,8 @@
---
name: integrations_test_webhook_reorder
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53433
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/320861
milestone: '13.9'
type: development
group: group::ecosystem
default_enabled: false

2
config/known_invalid_graphql_queries.yml
View File

@ -1,5 +1,5 @@
---
filenames:
- ee/app/assets/javascripts/on_demand_scans/graphql/dast_scan_create.mutation.graphql
- ee/app/assets/javascripts/oncall_schedules/graphql/mutations/update_oncall_schedule_rotation.mutation.graphql
- ee/app/assets/javascripts/security_configuration/api_fuzzing/graphql/api_fuzzing_ci_configuration.query.graphql
- ee/app/assets/javascripts/on_demand_scans/graphql/dast_profile_update.mutation.graphql

2
doc/README.md
View File

@ -29,7 +29,7 @@ No matter how you use GitLab, we have documentation for you.
| [**Contributing to GitLab**](#contributing-to-gitlab)<br/>At GitLab, everyone can contribute! | [**New to Git and GitLab?**](#new-to-git-and-gitlab)<br/>We have the resources to get you started. |
| [**Build an integration with GitLab**](#build-an-integration-with-gitlab)<br/>Consult our integration documentation. | [**Coming to GitLab from another platform?**](#coming-to-gitlab-from-another-platform)<br/>Consult our guides. |
| [**Install GitLab**](https://about.gitlab.com/install/)<br/>Installation options for different platforms. | [**Customers**](subscriptions/index.md)<br/>Information for new and existing customers. |
| [**Update GitLab**](update/README.md)<br/>Update your GitLab self-managed instance to the latest version. | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab reference architectures. |
| [**Update GitLab**](update/index.md)<br/>Update your GitLab self-managed instance to the latest version. | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab reference architectures. |
| [**GitLab releases**](https://about.gitlab.com/releases/)<br/>What's new in GitLab. | |
## Popular topics

12
doc/administration/index.md
View File

@ -32,7 +32,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
### Installing GitLab
- [Install](../install/README.md): Requirements, directory structures, and installation methods.
- [Install](../install/index.md): Requirements, directory structures, and installation methods.
- [Database load balancing](database_load_balancing.md): Distribute database queries among multiple database servers.
- [Omnibus support for log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
- [Reference architectures](reference_architectures/index.md): Add additional resources to support more users.
@ -92,7 +92,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
### Maintaining GitLab
- [Rake tasks](../raketasks/README.md): Perform various tasks for maintenance, backups, automatic webhooks setup, and more.
- [Rake tasks](../raketasks/index.md): Perform various tasks for maintenance, backups, automatic webhooks setup, and more.
- [Backup and restore](../raketasks/backup_restore.md): Backup and restore your GitLab instance.
- [Operations](operations/index.md): Keeping GitLab up and running (clean up Redis sessions, moving repositories, Sidekiq MemoryKiller, Puma).
- [Restart GitLab](restart_gitlab.md): Learn how to restart GitLab and its components.
@ -103,14 +103,14 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [GitLab versions and maintenance policy](../policy/maintenance.md): Understand GitLab versions and releases (Major, Minor, Patch, Security), as well as update recommendations.
- [GitLab in maintenance mode](maintenance_mode/index.md): Put GitLab in maintenance mode.
- [Update GitLab](../update/README.md): Update guides to upgrade your installation to a new version.
- [Upgrading without downtime](../update/README.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
- [Update GitLab](../update/index.md): Update guides to upgrade your installation to a new version.
- [Upgrading without downtime](../update/index.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
- [Migrate your GitLab CI/CD data to another version of GitLab](../migrate_ci_to_ce/README.md): If you have an old GitLab installation (older than 8.0), follow this guide to migrate your existing GitLab CI/CD data to another version of GitLab.
### Upgrading or downgrading GitLab
- [Upgrade from GitLab CE to GitLab EE](../update/README.md#upgrading-between-editions): learn how to upgrade GitLab Community Edition to GitLab Enterprise Editions.
- [Downgrade from GitLab EE to GitLab CE](../downgrade_ee_to_ce/README.md): Learn how to downgrade GitLab Enterprise Editions to Community Edition.
- [Upgrade from GitLab CE to GitLab EE](../update/index.md#upgrading-between-editions): learn how to upgrade GitLab Community Edition to GitLab Enterprise Editions.
- [Downgrade from GitLab EE to GitLab CE](../downgrade_ee_to_ce/index.md): Learn how to downgrade GitLab Enterprise Editions to Community Edition.
### GitLab platform integrations

2
doc/administration/operations/index.md
View File

@ -13,7 +13,7 @@ Keep your GitLab instance up and running smoothly.
you have been running a large GitLab server (thousands of users) since before
GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis
database after you upgrade to GitLab 7.3.
- [Rake tasks](../../raketasks/README.md): Tasks for common administration and operational processes such as
- [Rake tasks](../../raketasks/index.md): Tasks for common administration and operational processes such as
[cleaning up unneeded items from GitLab instance](../../raketasks/cleanup.md), integrity checks,
and more.
- [Moving repositories](moving_repositories.md): Moving all repositories managed

2
doc/administration/raketasks/maintenance.md
View File

@ -292,7 +292,7 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
## Display status of database migrations
See the [upgrade documentation](../../update/README.md#checking-for-background-migrations-before-upgrading)
See the [upgrade documentation](../../update/index.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:

2
doc/administration/reference_architectures/1k_users.md
View File

@ -41,7 +41,7 @@ the swap available when needed.
## Setup instructions
To install GitLab for this default reference architecture, use the standard
[installation instructions](../../install/README.md).
[installation instructions](../../install/index.md).
You can also optionally configure GitLab to use an [external PostgreSQL service](../postgresql/external.md)
or an [external object storage service](../object_storage.md) for added

2
doc/administration/reference_architectures/index.md
View File

@ -33,7 +33,7 @@ per 1,000 users:
For GitLab instances with less than 2,000 users, it's recommended that you use
the [default setup](#automated-backups) by
[installing GitLab](../../install/README.md) on a single machine to minimize
[installing GitLab](../../install/index.md) on a single machine to minimize
maintenance and resource costs.
If your organization has more than 2,000 users, the recommendation is to scale the

3
doc/ci/parent_child_pipelines.md
View File

@ -180,6 +180,9 @@ pipelines, which was later increased to two. A parent pipeline can trigger many
pipelines, and these child pipelines can trigger their own child pipelines. It's not
possible to trigger another level of child pipelines.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview, see [Nested Dynamic Pipelines](https://youtu.be/C5j3ju9je2M).
## Pass variables to a child pipeline
You can [pass variables to a downstream pipeline](multi_project_pipelines.md#passing-variables-to-a-downstream-pipeline)

5
doc/development/database_review.md
View File

@ -144,7 +144,10 @@ test its execution using `CREATE INDEX CONCURRENTLY` in the `#database-lab` Slac
##### Query Plans
- The query plan for each raw SQL query included in the merge request along with the link to the query plan following each raw SQL snippet.
- Provide the link to the plan at: [explain.depesz.com](https://explain.depesz.com). Paste both the plan and the query used in the form.
- Provide a public link to the plan from either:
- [postgres.ai](https://postgres.ai/): Follow the link in `#database-lab` and generate a shareable, public link
by clicking the **Share** button in the upper right corner.
- [explain.depesz.com](https://explain.depesz.com): Paste both the plan and the query used in the form.
- When providing query plans, make sure it hits enough data:
- You can use a GitLab production replica to test your queries on a large scale,
through the `#database-lab` Slack channel or through [ChatOps](understanding_explain_plans.md#chatops).

97
doc/downgrade_ee_to_ce/README.md
View File

@ -1,97 +1,8 @@
---
stage: none
group: unassigned
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
redirect_to: 'index.md'
---
# Downgrading from EE to CE
This document was moved to [another location](index.md).
If you ever decide to downgrade your Enterprise Edition back to the Community
Edition, there are a few steps you need take before installing the CE package
on top of the current EE package, or, if you are in an installation from source,
before you change remotes and fetch the latest CE code.
## Disable Enterprise-only features
First thing to do is to disable the following features.
### Authentication mechanisms
Kerberos and Atlassian Crowd are only available on the Enterprise Edition, so
you should disable these mechanisms before downgrading and you should provide
alternative authentication methods to your users.
### Remove Service Integration entries from the database
The `GithubService` class is only available in the Enterprise Edition codebase,
so if you downgrade to the Community Edition, the following error displays:
```plaintext
Completed 500 Internal Server Error in 497ms (ActiveRecord: 32.2ms)
ActionView::Template::Error (The single-table inheritance mechanism failed to locate the subclass: 'GithubService'. This
error is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this
column if you didn't intend it to be used for storing the inheritance class or overwrite Service.inheritance_column to
use another column for that information.)
```
All services are created automatically for every project you have, so in order
to avoid getting this error, you need to remove all instances of the
`GithubService` from your database:
**Omnibus Installation**
```shell
sudo gitlab-rails runner "Service.where(type: ['GithubService']).delete_all"
```
**Source Installation**
```shell
bundle exec rails runner "Service.where(type: ['GithubService']).delete_all" production
```
NOTE:
If you are running `GitLab =< v13.0` you need to also remove `JenkinsDeprecatedService` records
and if you are running `GitLab =< v13.6` you need to also remove `JenkinsService` records.
### Variables environment scopes
If you're using this feature and there are variables sharing the same
key, but they have different scopes in a project, then you might want to
revisit the environment scope setting for those variables.
In CE, environment scopes are completely ignored, therefore you could
accidentally get a variable which you're not expecting for a particular
environment. Make sure that you have the right variables in this case.
Data is completely preserved, so you could always upgrade back to EE and
restore the behavior if you leave it alone.
## Downgrade to CE
After performing the above mentioned steps, you are now ready to downgrade your
GitLab installation to the Community Edition.
**Omnibus Installation**
To downgrade an Omnibus installation, it is sufficient to install the Community
Edition package on top of the currently installed one. You can do this manually,
by directly [downloading the package](https://packages.gitlab.com/gitlab/gitlab-ce)
you need, or by adding our CE package repository and following the
[CE installation instructions](https://about.gitlab.com/install/?version=ce).
**Source Installation**
To downgrade a source installation, you need to replace the current remote of
your GitLab installation with the Community Edition's remote, fetch the latest
changes, and checkout the latest stable branch:
```shell
git remote set-url origin git@gitlab.com:gitlab-org/gitlab-foss.git
git fetch --all
git checkout 8-x-stable
```
Remember to follow the correct [update guides](../update/README.md) to make
sure all dependencies are up to date.
<!-- This redirect file can be deleted after 2021-05-11. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

97
doc/downgrade_ee_to_ce/index.md Normal file
View File

@ -0,0 +1,97 @@
---
stage: Enablement
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
---
# Downgrading from EE to CE
If you ever decide to downgrade your Enterprise Edition back to the Community
Edition, there are a few steps you need take before installing the CE package
on top of the current EE package, or, if you are in an installation from source,
before you change remotes and fetch the latest CE code.
## Disable Enterprise-only features
First thing to do is to disable the following features.
### Authentication mechanisms
Kerberos and Atlassian Crowd are only available on the Enterprise Edition, so
you should disable these mechanisms before downgrading and you should provide
alternative authentication methods to your users.
### Remove Service Integration entries from the database
The `GithubService` class is only available in the Enterprise Edition codebase,
so if you downgrade to the Community Edition, the following error displays:
```plaintext
Completed 500 Internal Server Error in 497ms (ActiveRecord: 32.2ms)
ActionView::Template::Error (The single-table inheritance mechanism failed to locate the subclass: 'GithubService'. This
error is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this
column if you didn't intend it to be used for storing the inheritance class or overwrite Service.inheritance_column to
use another column for that information.)
```
All services are created automatically for every project you have, so in order
to avoid getting this error, you need to remove all instances of the
`GithubService` from your database:
**Omnibus Installation**
```shell
sudo gitlab-rails runner "Service.where(type: ['GithubService']).delete_all"
```
**Source Installation**
```shell
bundle exec rails runner "Service.where(type: ['GithubService']).delete_all" production
```
NOTE:
If you are running `GitLab =< v13.0` you need to also remove `JenkinsDeprecatedService` records
and if you are running `GitLab =< v13.6` you need to also remove `JenkinsService` records.
### Variables environment scopes
If you're using this feature and there are variables sharing the same
key, but they have different scopes in a project, then you might want to
revisit the environment scope setting for those variables.
In CE, environment scopes are completely ignored, therefore you could
accidentally get a variable which you're not expecting for a particular
environment. Make sure that you have the right variables in this case.
Data is completely preserved, so you could always upgrade back to EE and
restore the behavior if you leave it alone.
## Downgrade to CE
After performing the above mentioned steps, you are now ready to downgrade your
GitLab installation to the Community Edition.
**Omnibus Installation**
To downgrade an Omnibus installation, it is sufficient to install the Community
Edition package on top of the currently installed one. You can do this manually,
by directly [downloading the package](https://packages.gitlab.com/gitlab/gitlab-ce)
you need, or by adding our CE package repository and following the
[CE installation instructions](https://about.gitlab.com/install/?version=ce).
**Source Installation**
To downgrade a source installation, you need to replace the current remote of
your GitLab installation with the Community Edition's remote, fetch the latest
changes, and checkout the latest stable branch:
```shell
git remote set-url origin git@gitlab.com:gitlab-org/gitlab-foss.git
git fetch --all
git checkout 8-x-stable
```
Remember to follow the correct [update guides](../update/index.md) to make
sure all dependencies are up to date.

143
doc/install/README.md
View File

@ -1,143 +1,8 @@
---
stage: Enablement
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
comments: false
description: Read through the GitLab installation methods.
type: index
redirect_to: 'index.md'
---
# Installation **(FREE SELF)**
This document was moved to [another location](index.md).
GitLab can be installed in most GNU/Linux distributions and with several
cloud providers. To get the best experience from GitLab, you must balance
performance, reliability, ease of administration (backups, upgrades, and
troubleshooting), and the cost of hosting.
Depending on your platform, select from the following available methods to
install GitLab:
- [_Omnibus GitLab_](#installing-gitlab-on-linux-using-the-omnibus-gitlab-package-recommended):
The official deb/rpm packages that contain a bundle of GitLab and the
components it depends on, including PostgreSQL, Redis, and Sidekiq.
- [_GitLab Helm chart_](#installing-gitlab-on-kubernetes-via-the-gitlab-helm-charts):
The cloud native Helm chart for installing GitLab and all of its components
on Kubernetes.
- [_Docker_](#installing-gitlab-with-docker): The Omnibus GitLab packages,
Dockerized.
- [_Source_](#installing-gitlab-from-source): Install GitLab and all of its
components from scratch.
- [_Cloud provider_](#installing-gitlab-on-cloud-providers): Install directly
from platforms like AWS, Azure, and GCP.
If you're not sure which installation method to use, we recommend you use
Omnibus GitLab. The Omnibus GitLab packages are mature,
[scalable](../administration/reference_architectures/index.md), and are used
today on GitLab.com. The Helm charts are recommended for those who are familiar
with Kubernetes.
## Requirements
Before you install GitLab, be sure to review the [system requirements](requirements.md).
The system requirements include details about the minimum hardware, software,
database, and additional requirements to support GitLab.
## Installing GitLab on Linux using the Omnibus GitLab package (recommended)
The Omnibus GitLab package uses our official deb/rpm repositories, and is
recommended for most users.
If you need additional scale or resilience, we recommend deploying
GitLab as described in our [reference architecture documentation](../administration/reference_architectures/index.md).
[**> Install GitLab using the Omnibus GitLab package.**](https://about.gitlab.com/install/)
### GitLab Environment Toolkit (alpha)
The [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit) provides a set of automation tools to easily deploy a [reference architecture](../administration/reference_architectures/index.md) on most major cloud providers.
It is currently in alpha, and is not recommended for production use.
[**> Install a GitLab reference architecture using the GitLab Environment Toolkit.**](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit#documentation)
## Installing GitLab on Kubernetes via the GitLab Helm charts
When installing GitLab on Kubernetes, there are some trade-offs that you
need to be aware of:
- Administration and troubleshooting requires Kubernetes knowledge.
- It can be more expensive for smaller installations. The default installation
requires more resources than a single node Omnibus deployment, as most services
are deployed in a redundant fashion.
- There are some feature [limitations to be aware of](https://docs.gitlab.com/charts/#limitations).
Due to these trade-offs, having Kubernetes experience is a requirement for
using this method. We recommend being familiar with Kubernetes before using it
to deploy GitLab in production. The methods for management, observability, and
some concepts are different than traditional deployments.
[**> Install GitLab on Kubernetes using the GitLab Helm charts.**](https://docs.gitlab.com/charts/)
## Installing GitLab with Docker
GitLab maintains a set of official Docker images based on the Omnibus GitLab
package.
[**> Install GitLab using the official GitLab Docker images.**](docker.md)
## Installing GitLab from source
If the Omnibus GitLab package isn't available for your distribution, you can
install GitLab from source. This can be useful with unsupported systems, like
\*BSD. For an overview of the directory structure, see the
[structure documentation](installation.md#gitlab-directory-structure).
[**> Install GitLab from source.**](installation.md)
## Installing GitLab on cloud providers
GitLab can be installed on a variety of cloud providers by using any of
the above methods, provided the cloud provider supports it.
- [Install on AWS](aws/index.md): Install Omnibus GitLab on AWS using the community AMIs that GitLab provides.
- [Install GitLab on Google Cloud Platform](google_cloud_platform/index.md): Install Omnibus GitLab on a VM in GCP.
- [Install GitLab on Azure](azure/index.md): Install Omnibus GitLab from Azure Marketplace.
- [Install GitLab on OpenShift](https://docs.gitlab.com/charts/installation/cloud/openshift.html): Install GitLab on OpenShift by using the GitLab Helm charts.
- [Install GitLab on DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-18-04): Install Omnibus GitLab on DigitalOcean.
- _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
Quickly test any version of GitLab on DigitalOcean using Docker Machine.
## Next steps
Here are a few resources you might want to check out after completing the
installation:
- [Upload a license](../user/admin_area/license.md) or [start a free trial](https://about.gitlab.com/free-trial/):
Activate all GitLab Enterprise Edition functionality with a license.
- [Set up runners](https://docs.gitlab.com/runner/): Set up one or more GitLab
Runners, the agents that are responsible for all of the GitLab CI/CD features.
- [GitLab Pages](../administration/pages/index.md): Configure GitLab Pages to
allow hosting of static sites.
- [GitLab Registry](../administration/packages/container_registry.md): With the
GitLab Container Registry, every project can have its own space to store Docker
images.
- [Secure GitLab](../security/README.md#securing-your-gitlab-installation):
Recommended practices to secure your GitLab instance.
- [SMTP](https://docs.gitlab.com/omnibus/settings/smtp.html): Configure SMTP
for proper email notifications support.
- [LDAP](../administration/auth/ldap/index.md): Configure LDAP to be used as
an authentication mechanism for GitLab.
- [Back up and restore GitLab](../raketasks/backup_restore.md): Learn the different
ways you can back up or restore GitLab.
- [Upgrade GitLab](../update/README.md): Every 22nd of the month, a new feature-rich GitLab version
is released. Learn how to upgrade to it, or to an interim release that contains a security fix.
- [Scaling GitLab](../administration/reference_architectures/index.md):
GitLab supports several different types of clustering.
- [Advanced Search](../integration/elasticsearch.md): Leverage Elasticsearch for
faster, more advanced code search across your entire GitLab instance.
- [Geo replication](../administration/geo/index.md):
Geo is the solution for widely distributed development teams.
- [Release and maintenance policy](../policy/maintenance.md): Learn about GitLab
policies governing version naming, as well as release pace for major, minor, patch,
and security releases.
- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
<!-- This redirect file can be deleted after 2021-05-11. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

143
doc/install/index.md Normal file
View File

@ -0,0 +1,143 @@
---
stage: Enablement
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
comments: false
description: Read through the GitLab installation methods.
type: index
---
# Installation **(FREE SELF)**
GitLab can be installed in most GNU/Linux distributions and with several
cloud providers. To get the best experience from GitLab, you must balance
performance, reliability, ease of administration (backups, upgrades, and
troubleshooting), and the cost of hosting.
Depending on your platform, select from the following available methods to
install GitLab:
- [_Omnibus GitLab_](#installing-gitlab-on-linux-using-the-omnibus-gitlab-package-recommended):
The official deb/rpm packages that contain a bundle of GitLab and the
components it depends on, including PostgreSQL, Redis, and Sidekiq.
- [_GitLab Helm chart_](#installing-gitlab-on-kubernetes-via-the-gitlab-helm-charts):
The cloud native Helm chart for installing GitLab and all of its components
on Kubernetes.
- [_Docker_](#installing-gitlab-with-docker): The Omnibus GitLab packages,
Dockerized.
- [_Source_](#installing-gitlab-from-source): Install GitLab and all of its
components from scratch.
- [_Cloud provider_](#installing-gitlab-on-cloud-providers): Install directly
from platforms like AWS, Azure, and GCP.
If you're not sure which installation method to use, we recommend you use
Omnibus GitLab. The Omnibus GitLab packages are mature,
[scalable](../administration/reference_architectures/index.md), and are used
today on GitLab.com. The Helm charts are recommended for those who are familiar
with Kubernetes.
## Requirements
Before you install GitLab, be sure to review the [system requirements](requirements.md).
The system requirements include details about the minimum hardware, software,
database, and additional requirements to support GitLab.
## Installing GitLab on Linux using the Omnibus GitLab package (recommended)
The Omnibus GitLab package uses our official deb/rpm repositories, and is
recommended for most users.
If you need additional scale or resilience, we recommend deploying
GitLab as described in our [reference architecture documentation](../administration/reference_architectures/index.md).
[**> Install GitLab using the Omnibus GitLab package.**](https://about.gitlab.com/install/)
### GitLab Environment Toolkit (alpha)
The [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit) provides a set of automation tools to easily deploy a [reference architecture](../administration/reference_architectures/index.md) on most major cloud providers.
It is currently in alpha, and is not recommended for production use.
[**> Install a GitLab reference architecture using the GitLab Environment Toolkit.**](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit#documentation)
## Installing GitLab on Kubernetes via the GitLab Helm charts
When installing GitLab on Kubernetes, there are some trade-offs that you
need to be aware of:
- Administration and troubleshooting requires Kubernetes knowledge.
- It can be more expensive for smaller installations. The default installation
requires more resources than a single node Omnibus deployment, as most services
are deployed in a redundant fashion.
- There are some feature [limitations to be aware of](https://docs.gitlab.com/charts/#limitations).
Due to these trade-offs, having Kubernetes experience is a requirement for
using this method. We recommend being familiar with Kubernetes before using it
to deploy GitLab in production. The methods for management, observability, and
some concepts are different than traditional deployments.
[**> Install GitLab on Kubernetes using the GitLab Helm charts.**](https://docs.gitlab.com/charts/)
## Installing GitLab with Docker
GitLab maintains a set of official Docker images based on the Omnibus GitLab
package.
[**> Install GitLab using the official GitLab Docker images.**](docker.md)
## Installing GitLab from source
If the Omnibus GitLab package isn't available for your distribution, you can
install GitLab from source. This can be useful with unsupported systems, like
\*BSD. For an overview of the directory structure, see the
[structure documentation](installation.md#gitlab-directory-structure).
[**> Install GitLab from source.**](installation.md)
## Installing GitLab on cloud providers
GitLab can be installed on a variety of cloud providers by using any of
the above methods, provided the cloud provider supports it.
- [Install on AWS](aws/index.md): Install Omnibus GitLab on AWS using the community AMIs that GitLab provides.
- [Install GitLab on Google Cloud Platform](google_cloud_platform/index.md): Install Omnibus GitLab on a VM in GCP.
- [Install GitLab on Azure](azure/index.md): Install Omnibus GitLab from Azure Marketplace.
- [Install GitLab on OpenShift](https://docs.gitlab.com/charts/installation/cloud/openshift.html): Install GitLab on OpenShift by using the GitLab Helm charts.
- [Install GitLab on DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-18-04): Install Omnibus GitLab on DigitalOcean.
- _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
Quickly test any version of GitLab on DigitalOcean using Docker Machine.
## Next steps
Here are a few resources you might want to check out after completing the
installation:
- [Upload a license](../user/admin_area/license.md) or [start a free trial](https://about.gitlab.com/free-trial/):
Activate all GitLab Enterprise Edition functionality with a license.
- [Set up runners](https://docs.gitlab.com/runner/): Set up one or more GitLab
Runners, the agents that are responsible for all of the GitLab CI/CD features.
- [GitLab Pages](../administration/pages/index.md): Configure GitLab Pages to
allow hosting of static sites.
- [GitLab Registry](../administration/packages/container_registry.md): With the
GitLab Container Registry, every project can have its own space to store Docker
images.
- [Secure GitLab](../security/README.md#securing-your-gitlab-installation):
Recommended practices to secure your GitLab instance.
- [SMTP](https://docs.gitlab.com/omnibus/settings/smtp.html): Configure SMTP
for proper email notifications support.
- [LDAP](../administration/auth/ldap/index.md): Configure LDAP to be used as
an authentication mechanism for GitLab.
- [Back up and restore GitLab](../raketasks/backup_restore.md): Learn the different
ways you can back up or restore GitLab.
- [Upgrade GitLab](../update/index.md): Every 22nd of the month, a new feature-rich GitLab version
is released. Learn how to upgrade to it, or to an interim release that contains a security fix.
- [Scaling GitLab](../administration/reference_architectures/index.md):
GitLab supports several different types of clustering.
- [Advanced Search](../integration/elasticsearch.md): Leverage Elasticsearch for
faster, more advanced code search across your entire GitLab instance.
- [Geo replication](../administration/geo/index.md):
Geo is the solution for widely distributed development teams.
- [Release and maintenance policy](../policy/maintenance.md): Learn about GitLab
policies governing version naming, as well as release pace for major, minor, patch,
and security releases.
- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.

2
doc/install/installation.md
View File

@ -9,7 +9,7 @@ type: howto
This is the official installation guide to set up a production GitLab server
using the source files. To set up a **development installation** or for many
other installation options, see the [main installation page](README.md).
other installation options, see the [main installation page](index.md).
It was created for and tested on **Debian/Ubuntu** operating systems.
Read [requirements.md](requirements.md) for hardware and operating system requirements.
If you want to install on RHEL/CentOS, we recommend using the

2
doc/install/requirements.md
View File

@ -22,7 +22,7 @@ as the hardware requirements that are needed to install and use GitLab.
- Scientific Linux (please use the CentOS packages and instructions)
- Oracle Linux (please use the CentOS packages and instructions)
For the installation options, see [the main installation page](README.md).
For the installation options, see [the main installation page](index.md).
### Unsupported Linux distributions and Unix-like operating systems

12
doc/operations/feature_flags.md
View File

@ -236,6 +236,18 @@ It can be set to:
of specific users IDs to enable the feature for.
- [User IDs](#user-ids)
## Legacy feature flag migration
Legacy feature flags became read-only in GitLab 13.4. GitLab 14.0 removes support for legacy feature
flags. You must migrate your legacy feature flags to the new version. To do so, follow these steps:
1. Take a screenshot of the legacy flag for tracking.
1. Delete the flag through the API or UI (you don't need to alter the code).
1. Create a new feature flag with the same name as the legacy flag you deleted. Make sure the
strategies and environments match the deleted flag.
See [this video tutorial](https://www.youtube.com/watch?v=CAJY2IGep7Y) for help with this migration.
## Disable a feature flag for a specific environment
In [GitLab 13.0 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/8621),

2
doc/policy/maintenance.md
View File

@ -74,7 +74,7 @@ A step-by-step guide to [upgrading the Omnibus-bundled PostgreSQL is documented
## Upgrading major versions
Backward-incompatible changes and migrations are reserved for major versions. See the [upgrade guide](../update/README.md#upgrading-to-a-new-major-version).
Backward-incompatible changes and migrations are reserved for major versions. See the [upgrade guide](../update/index.md#upgrading-to-a-new-major-version).
## Patch releases

48
doc/raketasks/README.md
View File

@ -1,48 +1,8 @@
---
stage: none
group: unassigned
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
comments: false
redirect_to: 'index.md'
---
# Rake tasks **(FREE SELF)**
This document was moved to [another location](index.md).
GitLab provides [Rake](https://ruby.github.io/rake/) tasks for common administration and operational processes.
GitLab Rake tasks are performed using:
- `gitlab-rake <raketask>` for [Omnibus GitLab](https://docs.gitlab.com/omnibus/README.html) installations.
- `bundle exec rake <raketask>` for [source](../install/installation.md) installations.
## Available Rake tasks
The following are available Rake tasks:
| Tasks | Description |
|:----------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------|
| [Back up and restore](backup_restore.md) | Back up, restore, and migrate GitLab instances between servers. |
| [Clean up](cleanup.md) | Clean up unneeded items from GitLab instances. |
| [Development](../development/rake_tasks.md) | Tasks for GitLab contributors. |
| [Doctor tasks](../administration/raketasks/doctor.md) | Checks for data integrity issues. |
| [Elasticsearch](../integration/elasticsearch.md#gitlab-advanced-search-rake-tasks) **(PREMIUM SELF)** | 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 SELF)** | [Geo](../administration/geo/index.md)-related maintenance. |
| [GitHub import](../administration/raketasks/github_import.md) | Retrieve and import repositories from GitHub. |
| [Import repositories](import.md) | Import bare repositories into your GitLab instance. |
| [Import large project exports](../development/import_project.md#importing-via-a-rake-task) | Import large GitLab [project exports](../user/project/settings/import_export.md). |
| [Integrity checks](../administration/raketasks/check.md) | Check the integrity of repositories, files, and LDAP. |
| [LDAP maintenance](../administration/raketasks/ldap.md) | [LDAP](../administration/auth/ldap/index.md)-related tasks. |
| [List repositories](list_repos.md) | List of all GitLab-managed Git repositories on disk. |
| [Migrate Snippets to Git](migrate_snippets.md) | Migrate GitLab Snippets to Git repositories and show migration status |
| [Praefect Rake tasks](../administration/raketasks/praefect.md) | [Praefect](../administration/gitaly/praefect.md)-related tasks. |
| [Project import/export](../administration/raketasks/project_import_export.md) | Prepare for [project exports and imports](../user/project/settings/import_export.md). |
| [Sample Prometheus data](generate_sample_prometheus_data.md) | Generate sample Prometheus data. |
| [SPDX license list import](spdx.md) **(PREMIUM SELF)** | Import a local copy of the [SPDX license list](https://spdx.org/licenses/) for matching [License Compliance policies](../user/compliance/license_compliance/index.md).| |
| [Repository storage](../administration/raketasks/storage.md) | List and migrate existing projects and attachments from legacy storage to hashed storage. |
| [Uploads migrate](../administration/raketasks/uploads/migrate.md) | Migrate uploads between storage local and object storage. |
| [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping) | Generate and troubleshoot [Usage Ping](../development/usage_ping.md).|
| [User management](user_management.md) | Perform user management tasks. |
| [Webhooks administration](web_hooks.md) | Maintain project Webhooks. |
| [X.509 signatures](x509_signatures.md) | Update X.509 commit signatures, useful if certificate store has changed. |
<!-- This redirect file can be deleted after 2021-05-11. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

2
doc/raketasks/backup_restore.md
View File

@ -1024,7 +1024,7 @@ restoring a single project or group, you can use a workaround by restoring
your backup to a separate, temporary GitLab instance, and then export your
project or group from there:
1. [Install a new GitLab](../install/README.md) instance at the same version as
1. [Install a new GitLab](../install/index.md) instance at the same version as
the backed-up instance from which you want to restore.
1. [Restore the backup](#restore-gitlab) into this new instance, then
export your [project](../user/project/settings/import_export.md)

48
doc/raketasks/index.md Normal file
View File

@ -0,0 +1,48 @@
---
stage: none
group: unassigned
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
comments: false
---
# Rake tasks **(FREE SELF)**
GitLab provides [Rake](https://ruby.github.io/rake/) tasks for common administration and operational processes.
GitLab Rake tasks are performed using:
- `gitlab-rake <raketask>` for [Omnibus GitLab](https://docs.gitlab.com/omnibus/README.html) installations.
- `bundle exec rake <raketask>` for [source](../install/installation.md) installations.
## Available Rake tasks
The following are available Rake tasks:
| Tasks | Description |
|:----------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------|
| [Back up and restore](backup_restore.md) | Back up, restore, and migrate GitLab instances between servers. |
| [Clean up](cleanup.md) | Clean up unneeded items from GitLab instances. |
| [Development](../development/rake_tasks.md) | Tasks for GitLab contributors. |
| [Doctor tasks](../administration/raketasks/doctor.md) | Checks for data integrity issues. |
| [Elasticsearch](../integration/elasticsearch.md#gitlab-advanced-search-rake-tasks) **(PREMIUM SELF)** | 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 SELF)** | [Geo](../administration/geo/index.md)-related maintenance. |
| [GitHub import](../administration/raketasks/github_import.md) | Retrieve and import repositories from GitHub. |
| [Import repositories](import.md) | Import bare repositories into your GitLab instance. |
| [Import large project exports](../development/import_project.md#importing-via-a-rake-task) | Import large GitLab [project exports](../user/project/settings/import_export.md). |
| [Integrity checks](../administration/raketasks/check.md) | Check the integrity of repositories, files, and LDAP. |
| [LDAP maintenance](../administration/raketasks/ldap.md) | [LDAP](../administration/auth/ldap/index.md)-related tasks. |
| [List repositories](list_repos.md) | List of all GitLab-managed Git repositories on disk. |
| [Migrate Snippets to Git](migrate_snippets.md) | Migrate GitLab Snippets to Git repositories and show migration status |
| [Praefect Rake tasks](../administration/raketasks/praefect.md) | [Praefect](../administration/gitaly/praefect.md)-related tasks. |
| [Project import/export](../administration/raketasks/project_import_export.md) | Prepare for [project exports and imports](../user/project/settings/import_export.md). |
| [Sample Prometheus data](generate_sample_prometheus_data.md) | Generate sample Prometheus data. |
| [SPDX license list import](spdx.md) **(PREMIUM SELF)** | Import a local copy of the [SPDX license list](https://spdx.org/licenses/) for matching [License Compliance policies](../user/compliance/license_compliance/index.md).| |
| [Repository storage](../administration/raketasks/storage.md) | List and migrate existing projects and attachments from legacy storage to hashed storage. |
| [Uploads migrate](../administration/raketasks/uploads/migrate.md) | Migrate uploads between storage local and object storage. |
| [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping) | Generate and troubleshoot [Usage Ping](../development/usage_ping.md).|
| [User management](user_management.md) | Perform user management tasks. |
| [Webhooks administration](web_hooks.md) | Maintain project Webhooks. |
| [X.509 signatures](x509_signatures.md) | Update X.509 commit signatures, useful if certificate store has changed. |

2
doc/topics/index.md
View File

@ -19,6 +19,6 @@ tutorials, technical overviews, blog posts) and videos.
- [Cron](cron/index.md)
- [Git](git/index.md)
- [GitLab Flow](gitlab_flow.md)
- [GitLab Installation](../install/README.md)
- [GitLab Installation](../install/index.md)
- [GitLab Pages](../user/project/pages/index.md)
- [Offline GitLab](offline/index.md)

423
doc/update/README.md
View File

@ -1,423 +1,8 @@
---
stage: Enablement
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
redirect_to: 'index.md'
---
# Upgrading GitLab
This document was moved to [another location](index.md).
Upgrading GitLab is a relatively straightforward process, but the complexity
can increase based on the installation method you have used, how old your
GitLab version is, if you're upgrading to a major version, and so on.
Make sure to read the whole page as it contains information related to every upgrade method.
The [maintenance policy documentation](../policy/maintenance.md)
has additional information about upgrading, including:
- How to interpret GitLab product versioning.
- Recommendations on the what release to run.
- How we use patch and security patch releases.
- When we backport code changes.
## Upgrade based on installation method
Depending on the installation method and your GitLab version, there are multiple
official ways to update GitLab:
- [Linux packages (Omnibus GitLab)](#linux-packages-omnibus-gitlab)
- [Source installations](#installation-from-source)
- [Docker installations](#installation-using-docker)
- [Kubernetes (Helm) installations](#installation-using-helm)
### Linux packages (Omnibus GitLab)
The [Omnibus update guide](https://docs.gitlab.com/omnibus/update/)
contains the steps needed to update a package installed by official GitLab
repositories.
There are also instructions when you want to
[update to a specific version](https://docs.gitlab.com/omnibus/update/#multi-step-upgrade-using-the-official-repositories).
### Installation from source
- [Upgrading Community Edition and Enterprise Edition from
source](upgrading_from_source.md) - The guidelines for upgrading Community
Edition and Enterprise Edition from source.
- [Patch versions](patch_versions.md) guide includes the steps needed for a
patch version, such as 13.2.0 to 13.2.1, and apply to both Community and Enterprise
Editions.
In the past we used separate documents for the upgrading instructions, but we
have since switched to using a single document. The old upgrading guidelines
can still be found in the Git repository:
- [Old upgrading guidelines for Community Edition](https://gitlab.com/gitlab-org/gitlab-foss/tree/11-8-stable/doc/update)
- [Old upgrading guidelines for Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/tree/11-8-stable-ee/doc/update)
### Installation using Docker
GitLab provides official Docker images for both Community and Enterprise
editions. They are based on the Omnibus package and instructions on how to
update them are in [a separate document](https://docs.gitlab.com/omnibus/docker/README.html).
### Installation using Helm
GitLab can be deployed into a Kubernetes cluster using Helm.
Instructions on how to update a cloud-native deployment are in
[a separate document](https://docs.gitlab.com/charts/installation/upgrade.html).
Use the [version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html)
from the chart version to GitLab version to determine the [upgrade path](#upgrade-paths).
## Checking for background migrations before upgrading
Certain major/minor releases may require a set of background migrations to be
finished. The number of remaining migrations jobs can be found by running the
following command:
**For Omnibus installations**
If using GitLab 12.9 and newer, run:
```shell
sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
```
If using GitLab 12.8 and older, run the following using a [Rails console](../administration/operations/rails_console.md#starting-a-rails-console-session):
```ruby
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
**For installations from source**
If using GitLab 12.9 and newer, run:
```shell
cd /home/git/gitlab
sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
```
If using GitLab 12.8 and older, run the following using a [Rails console](../administration/operations/rails_console.md#starting-a-rails-console-session):
```ruby
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
### What do I do if my background migrations are stuck?
WARNING:
The following operations can disrupt your GitLab performance.
It is safe to re-execute these commands, especially if you have 1000+ pending jobs which would likely overflow your runtime memory.
**For Omnibus installations**
```shell
# Start the rails console
sudo gitlab-rails c
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
```
**For installations from source**
```shell
# Start the rails console
sudo -u git -H bundle exec rails RAILS_ENV=production
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
```
## Upgrade paths
Although you can generally upgrade through multiple GitLab versions in one go,
sometimes this can cause issues.
Find where your version sits in the upgrade path below, and upgrade GitLab
accordingly, while also consulting the
[version-specific upgrade instructions](#version-specific-upgrading-instructions):
`8.11.x` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` -> `13.0.14` -> `13.1.11` - > `13.x (latest)`
The following table, while not exhaustive, shows some examples of the supported
upgrade paths.
| Target version | Your version | Supported upgrade path | Note |
| --------------------- | ------------ | ------------------------ | ---- |
| `13.4.3` | `12.9.2` | `12.9.2` -> `12.10.14` -> `13.0.14` -> `13.4.3` | Two intermediate versions are required: the final `12.10` release, plus `13.0`. |
| `13.2.10` | `11.5.0` | `11.5.0` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` -> `13.0.14` -> `13.2.10` | Five intermediate versions are required: the final `11.11`, `12.0`, `12.1` and `12.10` releases, plus `13.0`. |
| `12.10.14` | `11.3.4` | `11.3.4` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` | Three intermediate versions are required: the final `11.11` and `12.0` releases, plus `12.1` |
| `12.9.5` | `10.4.5` | `10.4.5` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.9.5` | Four intermediate versions are required: `10.8`, `11.11`, `12.0` and `12.1`, then `12.9.5` |
| `12.2.5` | `9.2.6` | `9.2.6` -> `9.5.10` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.2.5` | Five intermediate versions are required: `9.5`, `10.8`, `11.11`, `12.0`, `12.1`, then `12.2`. |
| `11.3.4` | `8.13.4` | `8.13.4` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> `11.3.4` | `8.17.7` is the last version in version 8, `9.5.10` is the last version in version 9, `10.8.7` is the last version in version 10. |
## Upgrading to a new major version
Upgrading the *major* version requires more attention.
Backward-incompatible changes and migrations are reserved for major versions.
We cannot guarantee that upgrading between major versions will be seamless.
It is suggested to upgrade to the latest available *minor* version within
your major version before proceeding to the next major version.
Doing this will address any backward-incompatible changes or deprecations
to help ensure a successful upgrade to the next major release.
Identify a [supported upgrade path](#upgrade-paths).
More significant migrations may occur during major release upgrades. To ensure these are successful:
1. Increment to the first minor version (`x.0.x`) during the major version jump.
1. Proceed with upgrading to a newer release.
It's also important to ensure that any background migrations have been fully completed
before upgrading to a new major version. To see the current size of the `background_migration` queue,
[Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
If your GitLab instance has any runners associated with it, it is very
important to upgrade GitLab Runner to match the GitLab minor version that was
upgraded to. This is to ensure [compatibility with GitLab versions](https://docs.gitlab.com/runner/#compatibility-with-gitlab-versions).
## Upgrading without downtime
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.
However, for this to work there are the following requirements:
- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
9.3.
- You have to use [post-deployment
migrations](../development/post_deployment_migrations.md) (included in
[zero downtime update steps below](#steps)).
- You are using PostgreSQL. Starting from GitLab 12.1, MySQL is not supported.
- Multi-node GitLab instance. Single-node instances may experience brief interruptions
[as services restart (Puma in particular)](https://docs.gitlab.com/omnibus/update/README.html#single-node-deployment).
Most of the time you can safely upgrade from a patch release to the next minor
release if the patch release is not the latest. For example, upgrading from
9.1.1 to 9.2.0 should be safe even if 9.1.2 has been released. We do recommend
you check the release posts of any releases between your current and target
version just in case they include any migrations that may require you to upgrade
1 release at a time.
Some releases may also include so called "background migrations". These
migrations are performed in the background by Sidekiq and are often used for
migrating data. Background migrations are only added in the monthly releases.
Certain major/minor releases may require a set of background migrations to be
finished. To guarantee this such a release will process any remaining jobs
before continuing the upgrading procedure. While this won't require downtime
(if the above conditions are met) we recommend users to keep at least 1 week
between upgrading major/minor releases, allowing the background migrations to
finish. The time necessary to complete these migrations can be reduced by
increasing the number of Sidekiq workers that can process jobs in the
`background_migration` queue. To see the size of this queue,
[Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
As a rule of thumb, any database smaller than 10 GB won't take too much time to
upgrade; perhaps an hour at most per minor release. Larger databases however may
require more time, but this is highly dependent on the size of the database and
the migrations that are being performed.
### Examples
To help explain this, let's look at some examples.
**Example 1:** You are running a large GitLab installation using version 9.4.2,
which is the latest patch release of 9.4. When GitLab 9.5.0 is released this
installation can be safely upgraded to 9.5.0 without requiring downtime if the
requirements mentioned above are met. You can also skip 9.5.0 and upgrade to
9.5.1 after it's released, but you **can not** upgrade straight to 9.6.0; you
_have_ to first upgrade to a 9.5.x release.
**Example 2:** You are running a large GitLab installation using version 9.4.2,
which is the latest patch release of 9.4. GitLab 9.5 includes some background
migrations, and 10.0 will require these to be completed (processing any
remaining jobs for you). Skipping 9.5 is not possible without downtime, and due
to the background migrations would require potentially hours of downtime
depending on how long it takes for the background migrations to complete. To
work around this you will have to upgrade to 9.5.x first, then wait at least a
week before upgrading to 10.0.
**Example 3:** You use MySQL as the database for GitLab. Any upgrade to a new
major/minor release will require downtime. If a release includes any background
migrations this could potentially lead to hours of downtime, depending on the
size of your database. To work around this you will have to use PostgreSQL and
meet the other online upgrade requirements mentioned above.
### Steps
Steps to [upgrade without downtime](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
## Upgrading between editions
GitLab comes in two flavors: [Community Edition](https://about.gitlab.com/features/#community) which is MIT licensed,
and [Enterprise Edition](https://about.gitlab.com/features/#enterprise) which builds on top of the Community Edition and
includes extra features mainly aimed at organizations with more than 100 users.
Below you can find some guides to help you change GitLab editions.
### Community to Enterprise Edition
NOTE:
The following guides are for subscribers of the Enterprise Edition only.
If you wish to upgrade your GitLab installation from Community to Enterprise
Edition, follow the guides below based on the installation method:
- [Source CE to EE update guides](upgrading_from_ce_to_ee.md) - The steps are very similar
to a version upgrade: stop the server, get the code, update configuration files for
the new functionality, install libraries and do migrations, update the init
script, start the application and check its status.
- [Omnibus CE to EE](https://docs.gitlab.com/omnibus/update/README.html#update-community-edition-to-enterprise-edition) - Follow this guide to update your Omnibus
GitLab Community Edition to the Enterprise Edition.
### Enterprise to Community Edition
If you need to downgrade your Enterprise Edition installation back to Community
Edition, you can follow [this guide](../downgrade_ee_to_ce/README.md) to make the process as smooth as
possible.
## Version-specific upgrading instructions
Each month, a major or minor release of GitLab is published along with a
[release post](https://about.gitlab.com/releases/categories/releases/).
You should check all the major and minor versions you're passing over.
At the end of those release posts, there are three sections to look for:
- Deprecations
- Removals
- Important notes on upgrading
These will include:
- Steps you need to perform as part of an upgrade.
For example [8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#upgrade-barometer)
required the Elasticsearch index to be recreated. Any older version of GitLab upgrading to 8.12 or higher would require this.
- Changes to the versions of software we support such as
[ceasing support for IE11 in GitLab 13](https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/#ending-support-for-internet-explorer-11).
Apart from the instructions in this section, you should also check the
installation-specific upgrade instructions, based on how you installed GitLab:
- [Linux packages (Omnibus GitLab)](https://docs.gitlab.com/omnibus/update/README.html#version-specific-changes)
- [Helm charts](https://docs.gitlab.com/charts/installation/upgrade.html)
NOTE:
Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
### 13.6.0
Ruby 2.7.2 is required. GitLab will not start with Ruby 2.6.6 or older versions.
The required Git version is Git v2.29 or higher.
### 13.3.0
The recommended Git version is Git v2.28. The minimum required version of Git
v2.24 remains the same.
### 13.2.0
GitLab installations that have multiple web nodes will need to be
[upgraded to 13.1](#1310) before upgrading to 13.2 (and later) due to a
breaking change in Rails that can result in authorization issues.
GitLab 13.2.0 [remediates](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35492) an [email verification bypass](https://about.gitlab.com/releases/2020/05/27/security-release-13-0-1-released/).
After upgrading, if some of your users are unexpectedly encountering 404 or 422 errors when signing in,
or "blocked" messages when using the command line,
their accounts may have been un-confirmed.
In that case, please ask them to check their email for a re-confirmation link.
For more information, see our discussion of [Email confirmation issues](../user/upgrade_email_bypass.md).
GitLab 13.2.0 relies on the `btree_gist` extension for PostgreSQL. For installations with an externally managed PostgreSQL setup, please make sure to
[install the extension manually](https://www.postgresql.org/docs/11/sql-createextension.html) before upgrading GitLab if the database user for GitLab
is not a superuser. This is not necessary for installations using a GitLab managed PostgreSQL database.
### 13.1.0
In 13.1.0, you must upgrade to either:
- At least Git v2.24 (previously, the minimum required version was Git v2.22).
- The recommended Git v2.26.
Failure to do so will result in internal errors in the Gitaly service in some RPCs due
to the use of the new `--end-of-options` Git flag.
Additionally, in GitLab 13.1.0, the version of [Rails was upgraded from 6.0.3 to
6.0.3.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33454).
The Rails upgrade included a change to CSRF token generation which is
not backwards-compatible - GitLab servers with the new Rails version
will generate CSRF tokens that are not recognizable by GitLab servers
with the older Rails version - which could cause non-GET requests to
fail for [multi-node GitLab installations](https://docs.gitlab.com/omnibus/update/#multi-node--ha-deployment).
So, if you are using multiple Rails servers and specifically upgrading from 13.0,
all servers must first be upgraded to 13.1.X before upgrading to 13.2.0 or later:
1. Ensure all GitLab web nodes are on GitLab 13.1.X.
1. Optionally, enable the `global_csrf_token` feature flag to enable new
method of CSRF token generation:
```ruby
Feature.enable(:global_csrf_token)
```
1. Only then, continue to upgrade to later versions of GitLab.
### 12.2.0
In 12.2.0, we enabled Rails' authenticated cookie encryption. Old sessions are
automatically upgraded.
However, session cookie downgrades are not supported. So after upgrading to 12.2.0,
any downgrades would result to all sessions being invalidated and users are logged out.
### 12.1.0
If you are planning to upgrade from `12.0.x` to `12.10.x`, it is necessary to
perform an intermediary upgrade to `12.1.x` before upgrading to `12.10.x` to
avoid issues like [#215141](https://gitlab.com/gitlab-org/gitlab/-/issues/215141).
### 12.0.0
In 12.0.0 we made various database related changes. These changes require that
users first upgrade to the latest 11.11 patch release. After upgraded to 11.11.x,
users can upgrade to 12.0.x. Failure to do so may result in database migrations
not being applied, which could lead to application errors.
It is also required that you upgrade to 12.0.x before moving to a later version
of 12.x.
Example 1: you are currently using GitLab 11.11.8, which is the latest patch
release for 11.11.x. You can upgrade as usual to 12.0.x.
Example 2: you are currently using a version of GitLab 10.x. To upgrade, first
upgrade to the last 10.x release (10.8.7) then the last 11.x release (11.11.8).
After upgraded to 11.11.8 you can safely upgrade to 12.0.x.
See our [documentation on upgrade paths](../policy/maintenance.md#upgrade-recommendations)
for more information.
### Upgrades from versions earlier than 8.12
- `8.11.x` and earlier: you might have to upgrade to `8.12.0` specifically before you can upgrade to `8.17.7`. This was [reported in an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/207259).
- [CI changes prior to version 8.0](https://docs.gitlab.com/omnibus/update/README.html#updating-gitlab-ci-from-prior-540-to-version-714-via-omnibus-gitlab)
when it was merged into GitLab.
## Miscellaneous
- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating
your database from MySQL to PostgreSQL.
- [Restoring from backup after a failed upgrade](restore_after_failure.md)
- [Upgrading PostgreSQL Using Slony](upgrading_postgresql_using_slony.md), for
upgrading a PostgreSQL database with minimal downtime.
- [Managing PostgreSQL extensions](../install/postgresql_extensions.md)
<!-- This redirect file can be deleted after 2021-05-11. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

423
doc/update/index.md Normal file
View File

@ -0,0 +1,423 @@
---
stage: Enablement
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
---
# Upgrading GitLab
Upgrading GitLab is a relatively straightforward process, but the complexity
can increase based on the installation method you have used, how old your
GitLab version is, if you're upgrading to a major version, and so on.
Make sure to read the whole page as it contains information related to every upgrade method.
The [maintenance policy documentation](../policy/maintenance.md)
has additional information about upgrading, including:
- How to interpret GitLab product versioning.
- Recommendations on the what release to run.
- How we use patch and security patch releases.
- When we backport code changes.
## Upgrade based on installation method
Depending on the installation method and your GitLab version, there are multiple
official ways to update GitLab:
- [Linux packages (Omnibus GitLab)](#linux-packages-omnibus-gitlab)
- [Source installations](#installation-from-source)
- [Docker installations](#installation-using-docker)
- [Kubernetes (Helm) installations](#installation-using-helm)
### Linux packages (Omnibus GitLab)
The [Omnibus update guide](https://docs.gitlab.com/omnibus/update/)
contains the steps needed to update a package installed by official GitLab
repositories.
There are also instructions when you want to
[update to a specific version](https://docs.gitlab.com/omnibus/update/#multi-step-upgrade-using-the-official-repositories).
### Installation from source
- [Upgrading Community Edition and Enterprise Edition from
source](upgrading_from_source.md) - The guidelines for upgrading Community
Edition and Enterprise Edition from source.
- [Patch versions](patch_versions.md) guide includes the steps needed for a
patch version, such as 13.2.0 to 13.2.1, and apply to both Community and Enterprise
Editions.
In the past we used separate documents for the upgrading instructions, but we
have since switched to using a single document. The old upgrading guidelines
can still be found in the Git repository:
- [Old upgrading guidelines for Community Edition](https://gitlab.com/gitlab-org/gitlab-foss/tree/11-8-stable/doc/update)
- [Old upgrading guidelines for Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/tree/11-8-stable-ee/doc/update)
### Installation using Docker
GitLab provides official Docker images for both Community and Enterprise
editions. They are based on the Omnibus package and instructions on how to
update them are in [a separate document](https://docs.gitlab.com/omnibus/docker/README.html).
### Installation using Helm
GitLab can be deployed into a Kubernetes cluster using Helm.
Instructions on how to update a cloud-native deployment are in
[a separate document](https://docs.gitlab.com/charts/installation/upgrade.html).
Use the [version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html)
from the chart version to GitLab version to determine the [upgrade path](#upgrade-paths).
## Checking for background migrations before upgrading
Certain major/minor releases may require a set of background migrations to be
finished. The number of remaining migrations jobs can be found by running the
following command:
**For Omnibus installations**
If using GitLab 12.9 and newer, run:
```shell
sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
```
If using GitLab 12.8 and older, run the following using a [Rails console](../administration/operations/rails_console.md#starting-a-rails-console-session):
```ruby
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
**For installations from source**
If using GitLab 12.9 and newer, run:
```shell
cd /home/git/gitlab
sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
```
If using GitLab 12.8 and older, run the following using a [Rails console](../administration/operations/rails_console.md#starting-a-rails-console-session):
```ruby
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
### What do I do if my background migrations are stuck?
WARNING:
The following operations can disrupt your GitLab performance.
It is safe to re-execute these commands, especially if you have 1000+ pending jobs which would likely overflow your runtime memory.
**For Omnibus installations**
```shell
# Start the rails console
sudo gitlab-rails c
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
```
**For installations from source**
```shell
# Start the rails console
sudo -u git -H bundle exec rails RAILS_ENV=production
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
```
## Upgrade paths
Although you can generally upgrade through multiple GitLab versions in one go,
sometimes this can cause issues.
Find where your version sits in the upgrade path below, and upgrade GitLab
accordingly, while also consulting the
[version-specific upgrade instructions](#version-specific-upgrading-instructions):
`8.11.x` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` -> `13.0.14` -> `13.1.11` - > `13.x (latest)`
The following table, while not exhaustive, shows some examples of the supported
upgrade paths.
| Target version | Your version | Supported upgrade path | Note |
| --------------------- | ------------ | ------------------------ | ---- |
| `13.4.3` | `12.9.2` | `12.9.2` -> `12.10.14` -> `13.0.14` -> `13.4.3` | Two intermediate versions are required: the final `12.10` release, plus `13.0`. |
| `13.2.10` | `11.5.0` | `11.5.0` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` -> `13.0.14` -> `13.2.10` | Five intermediate versions are required: the final `11.11`, `12.0`, `12.1` and `12.10` releases, plus `13.0`. |
| `12.10.14` | `11.3.4` | `11.3.4` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` | Three intermediate versions are required: the final `11.11` and `12.0` releases, plus `12.1` |
| `12.9.5` | `10.4.5` | `10.4.5` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.9.5` | Four intermediate versions are required: `10.8`, `11.11`, `12.0` and `12.1`, then `12.9.5` |
| `12.2.5` | `9.2.6` | `9.2.6` -> `9.5.10` -> `10.8.7` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.2.5` | Five intermediate versions are required: `9.5`, `10.8`, `11.11`, `12.0`, `12.1`, then `12.2`. |
| `11.3.4` | `8.13.4` | `8.13.4` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> `11.3.4` | `8.17.7` is the last version in version 8, `9.5.10` is the last version in version 9, `10.8.7` is the last version in version 10. |
## Upgrading to a new major version
Upgrading the *major* version requires more attention.
Backward-incompatible changes and migrations are reserved for major versions.
We cannot guarantee that upgrading between major versions will be seamless.
It is suggested to upgrade to the latest available *minor* version within
your major version before proceeding to the next major version.
Doing this will address any backward-incompatible changes or deprecations
to help ensure a successful upgrade to the next major release.
Identify a [supported upgrade path](#upgrade-paths).
More significant migrations may occur during major release upgrades. To ensure these are successful:
1. Increment to the first minor version (`x.0.x`) during the major version jump.
1. Proceed with upgrading to a newer release.
It's also important to ensure that any background migrations have been fully completed
before upgrading to a new major version. To see the current size of the `background_migration` queue,
[Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
If your GitLab instance has any runners associated with it, it is very
important to upgrade GitLab Runner to match the GitLab minor version that was
upgraded to. This is to ensure [compatibility with GitLab versions](https://docs.gitlab.com/runner/#compatibility-with-gitlab-versions).
## Upgrading without downtime
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.
However, for this to work there are the following requirements:
- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
9.3.
- You have to use [post-deployment
migrations](../development/post_deployment_migrations.md) (included in
[zero downtime update steps below](#steps)).
- You are using PostgreSQL. Starting from GitLab 12.1, MySQL is not supported.
- Multi-node GitLab instance. Single-node instances may experience brief interruptions
[as services restart (Puma in particular)](https://docs.gitlab.com/omnibus/update/README.html#single-node-deployment).
Most of the time you can safely upgrade from a patch release to the next minor
release if the patch release is not the latest. For example, upgrading from
9.1.1 to 9.2.0 should be safe even if 9.1.2 has been released. We do recommend
you check the release posts of any releases between your current and target
version just in case they include any migrations that may require you to upgrade
1 release at a time.
Some releases may also include so called "background migrations". These
migrations are performed in the background by Sidekiq and are often used for
migrating data. Background migrations are only added in the monthly releases.
Certain major/minor releases may require a set of background migrations to be
finished. To guarantee this such a release will process any remaining jobs
before continuing the upgrading procedure. While this won't require downtime
(if the above conditions are met) we recommend users to keep at least 1 week
between upgrading major/minor releases, allowing the background migrations to
finish. The time necessary to complete these migrations can be reduced by
increasing the number of Sidekiq workers that can process jobs in the
`background_migration` queue. To see the size of this queue,
[Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
As a rule of thumb, any database smaller than 10 GB won't take too much time to
upgrade; perhaps an hour at most per minor release. Larger databases however may
require more time, but this is highly dependent on the size of the database and
the migrations that are being performed.
### Examples
To help explain this, let's look at some examples.
**Example 1:** You are running a large GitLab installation using version 9.4.2,
which is the latest patch release of 9.4. When GitLab 9.5.0 is released this
installation can be safely upgraded to 9.5.0 without requiring downtime if the
requirements mentioned above are met. You can also skip 9.5.0 and upgrade to
9.5.1 after it's released, but you **can not** upgrade straight to 9.6.0; you
_have_ to first upgrade to a 9.5.x release.
**Example 2:** You are running a large GitLab installation using version 9.4.2,
which is the latest patch release of 9.4. GitLab 9.5 includes some background
migrations, and 10.0 will require these to be completed (processing any
remaining jobs for you). Skipping 9.5 is not possible without downtime, and due
to the background migrations would require potentially hours of downtime
depending on how long it takes for the background migrations to complete. To
work around this you will have to upgrade to 9.5.x first, then wait at least a
week before upgrading to 10.0.
**Example 3:** You use MySQL as the database for GitLab. Any upgrade to a new
major/minor release will require downtime. If a release includes any background
migrations this could potentially lead to hours of downtime, depending on the
size of your database. To work around this you will have to use PostgreSQL and
meet the other online upgrade requirements mentioned above.
### Steps
Steps to [upgrade without downtime](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
## Upgrading between editions
GitLab comes in two flavors: [Community Edition](https://about.gitlab.com/features/#community) which is MIT licensed,
and [Enterprise Edition](https://about.gitlab.com/features/#enterprise) which builds on top of the Community Edition and
includes extra features mainly aimed at organizations with more than 100 users.
Below you can find some guides to help you change GitLab editions.
### Community to Enterprise Edition
NOTE:
The following guides are for subscribers of the Enterprise Edition only.
If you wish to upgrade your GitLab installation from Community to Enterprise
Edition, follow the guides below based on the installation method:
- [Source CE to EE update guides](upgrading_from_ce_to_ee.md) - The steps are very similar
to a version upgrade: stop the server, get the code, update configuration files for
the new functionality, install libraries and do migrations, update the init
script, start the application and check its status.
- [Omnibus CE to EE](https://docs.gitlab.com/omnibus/update/README.html#update-community-edition-to-enterprise-edition) - Follow this guide to update your Omnibus
GitLab Community Edition to the Enterprise Edition.
### Enterprise to Community Edition
If you need to downgrade your Enterprise Edition installation back to Community
Edition, you can follow [this guide](../downgrade_ee_to_ce/index.md) to make the process as smooth as
possible.
## Version-specific upgrading instructions
Each month, a major or minor release of GitLab is published along with a
[release post](https://about.gitlab.com/releases/categories/releases/).
You should check all the major and minor versions you're passing over.
At the end of those release posts, there are three sections to look for:
- Deprecations
- Removals
- Important notes on upgrading
These will include:
- Steps you need to perform as part of an upgrade.
For example [8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#upgrade-barometer)
required the Elasticsearch index to be recreated. Any older version of GitLab upgrading to 8.12 or higher would require this.
- Changes to the versions of software we support such as
[ceasing support for IE11 in GitLab 13](https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/#ending-support-for-internet-explorer-11).
Apart from the instructions in this section, you should also check the
installation-specific upgrade instructions, based on how you installed GitLab:
- [Linux packages (Omnibus GitLab)](https://docs.gitlab.com/omnibus/update/README.html#version-specific-changes)
- [Helm charts](https://docs.gitlab.com/charts/installation/upgrade.html)
NOTE:
Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
### 13.6.0
Ruby 2.7.2 is required. GitLab will not start with Ruby 2.6.6 or older versions.
The required Git version is Git v2.29 or higher.
### 13.3.0
The recommended Git version is Git v2.28. The minimum required version of Git
v2.24 remains the same.
### 13.2.0
GitLab installations that have multiple web nodes will need to be
[upgraded to 13.1](#1310) before upgrading to 13.2 (and later) due to a
breaking change in Rails that can result in authorization issues.
GitLab 13.2.0 [remediates](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35492) an [email verification bypass](https://about.gitlab.com/releases/2020/05/27/security-release-13-0-1-released/).
After upgrading, if some of your users are unexpectedly encountering 404 or 422 errors when signing in,
or "blocked" messages when using the command line,
their accounts may have been un-confirmed.
In that case, please ask them to check their email for a re-confirmation link.
For more information, see our discussion of [Email confirmation issues](../user/upgrade_email_bypass.md).
GitLab 13.2.0 relies on the `btree_gist` extension for PostgreSQL. For installations with an externally managed PostgreSQL setup, please make sure to
[install the extension manually](https://www.postgresql.org/docs/11/sql-createextension.html) before upgrading GitLab if the database user for GitLab
is not a superuser. This is not necessary for installations using a GitLab managed PostgreSQL database.
### 13.1.0
In 13.1.0, you must upgrade to either:
- At least Git v2.24 (previously, the minimum required version was Git v2.22).
- The recommended Git v2.26.
Failure to do so will result in internal errors in the Gitaly service in some RPCs due
to the use of the new `--end-of-options` Git flag.
Additionally, in GitLab 13.1.0, the version of [Rails was upgraded from 6.0.3 to
6.0.3.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33454).
The Rails upgrade included a change to CSRF token generation which is
not backwards-compatible - GitLab servers with the new Rails version
will generate CSRF tokens that are not recognizable by GitLab servers
with the older Rails version - which could cause non-GET requests to
fail for [multi-node GitLab installations](https://docs.gitlab.com/omnibus/update/#multi-node--ha-deployment).
So, if you are using multiple Rails servers and specifically upgrading from 13.0,
all servers must first be upgraded to 13.1.X before upgrading to 13.2.0 or later:
1. Ensure all GitLab web nodes are on GitLab 13.1.X.
1. Optionally, enable the `global_csrf_token` feature flag to enable new
method of CSRF token generation:
```ruby
Feature.enable(:global_csrf_token)
```
1. Only then, continue to upgrade to later versions of GitLab.
### 12.2.0
In 12.2.0, we enabled Rails' authenticated cookie encryption. Old sessions are
automatically upgraded.
However, session cookie downgrades are not supported. So after upgrading to 12.2.0,
any downgrades would result to all sessions being invalidated and users are logged out.
### 12.1.0
If you are planning to upgrade from `12.0.x` to `12.10.x`, it is necessary to
perform an intermediary upgrade to `12.1.x` before upgrading to `12.10.x` to
avoid issues like [#215141](https://gitlab.com/gitlab-org/gitlab/-/issues/215141).
### 12.0.0
In 12.0.0 we made various database related changes. These changes require that
users first upgrade to the latest 11.11 patch release. After upgraded to 11.11.x,
users can upgrade to 12.0.x. Failure to do so may result in database migrations
not being applied, which could lead to application errors.
It is also required that you upgrade to 12.0.x before moving to a later version
of 12.x.
Example 1: you are currently using GitLab 11.11.8, which is the latest patch
release for 11.11.x. You can upgrade as usual to 12.0.x.
Example 2: you are currently using a version of GitLab 10.x. To upgrade, first
upgrade to the last 10.x release (10.8.7) then the last 11.x release (11.11.8).
After upgraded to 11.11.8 you can safely upgrade to 12.0.x.
See our [documentation on upgrade paths](../policy/maintenance.md#upgrade-recommendations)
for more information.
### Upgrades from versions earlier than 8.12
- `8.11.x` and earlier: you might have to upgrade to `8.12.0` specifically before you can upgrade to `8.17.7`. This was [reported in an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/207259).
- [CI changes prior to version 8.0](https://docs.gitlab.com/omnibus/update/README.html#updating-gitlab-ci-from-prior-540-to-version-714-via-omnibus-gitlab)
when it was merged into GitLab.
## Miscellaneous
- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating
your database from MySQL to PostgreSQL.
- [Restoring from backup after a failed upgrade](restore_after_failure.md)
- [Upgrading PostgreSQL Using Slony](upgrading_postgresql_using_slony.md), for
upgrading a PostgreSQL database with minimal downtime.
- [Managing PostgreSQL extensions](../install/postgresql_extensions.md)

2
doc/update/upgrading_from_source.md
View File

@ -35,7 +35,7 @@ to identify the ideal upgrade path.
Before upgrading to a new major version, you should ensure that any background
migration jobs from previous releases have been completed. To see the current size of the `background_migration` queue,
[Check for background migrations before upgrading](README.md#checking-for-background-migrations-before-upgrading).
[Check for background migrations before upgrading](index.md#checking-for-background-migrations-before-upgrading).
## Guidelines for all versions

4
doc/user/admin_area/license.md
View File

@ -13,7 +13,7 @@ you are running. To verify, sign in to GitLab and browse to `/help`. The GitLab
are listed at the top of the **Help** page.
If you are running GitLab Community Edition (CE), upgrade your installation to
GitLab Enterprise Edition (EE). For more details, see [Upgrading between editions](../../update/README.md#upgrading-between-editions).
GitLab Enterprise Edition (EE). For more details, see [Upgrading between editions](../../update/index.md#upgrading-between-editions).
If you have questions or need assistance upgrading from GitLab CE to EE please [contact GitLab Support](https://about.gitlab.com/support/#contact-support).
The license is a base64-encoded ASCII text file with a `.gitlab-license`
@ -133,7 +133,7 @@ The banner disappears after the new license becomes active.
### There is no License tab in the Admin Area
If you originally installed Community Edition rather than Enterprise Edition you must
[upgrade to Enterprise Edition](../../update/README.md#community-to-enterprise-edition)
[upgrade to Enterprise Edition](../../update/index.md#community-to-enterprise-edition)
before uploading your license.
GitLab.com users can't upload and use a self-managed license. If you

12
locale/gitlab.pot
View File

@ -26121,15 +26121,15 @@ msgstr ""
msgid "SecurityReports|Severity"
msgstr ""
msgid "SecurityReports|Sometimes a scanner can't determine a finding's severity. Those findings may still be a potential source of risk though. Please review these manually."
msgstr ""
msgid "SecurityReports|Sorry, your filter produced no results"
msgstr ""
msgid "SecurityReports|Status"
msgstr ""
msgid "SecurityReports|The rating \"unknown\" indicates that the underlying scanner doesn’t contain or provide a severity rating."
msgstr ""
msgid "SecurityReports|The security dashboard displays the latest security findings for projects you wish to monitor. Add projects to your group to view their vulnerabilities here."
msgstr ""
@ -28681,6 +28681,9 @@ msgstr ""
msgid "Terraform|Locked by %{user} %{timeAgo}"
msgstr ""
msgid "Terraform|Locking state"
msgstr ""
msgid "Terraform|Name"
msgstr ""
@ -28714,6 +28717,9 @@ msgstr ""
msgid "Terraform|Unlock"
msgstr ""
msgid "Terraform|Unlocking state"
msgstr ""
msgid "Terraform|You are about to remove the State file %{name}. This will permanently delete all the State versions and history. The infrastructure provisioned previously\twill remain intact, only the state file with all its versions are to be removed. This action is non-revertible."
msgstr ""

41
spec/frontend/pages/projects/merge_requests/edit/check_form_state_spec.js Normal file
View File

@ -0,0 +1,41 @@
import initCheckFormState from '~/pages/projects/merge_requests/edit/check_form_state';
describe('Check form state', () => {
const findInput = () => document.querySelector('#form-input');
let beforeUnloadEvent;
let setDialogContent;
beforeEach(() => {
setFixtures(`
<form class="merge-request-form">
<input type="text" name="test" id="form-input"/>
</form>`);
beforeUnloadEvent = new Event('beforeunload');
jest.spyOn(beforeUnloadEvent, 'preventDefault');
setDialogContent = jest.spyOn(beforeUnloadEvent, 'returnValue', 'set');
initCheckFormState();
});
afterEach(() => {
beforeUnloadEvent.preventDefault.mockRestore();
setDialogContent.mockRestore();
});
it('shows confirmation dialog when there are unsaved changes', () => {
findInput().value = 'value changed';
window.dispatchEvent(beforeUnloadEvent);
expect(beforeUnloadEvent.preventDefault).toHaveBeenCalled();
expect(setDialogContent).toHaveBeenCalledWith('');
});
it('does not show confirmation dialog when there are no unsaved changes', () => {
window.dispatchEvent(beforeUnloadEvent);
expect(beforeUnloadEvent.preventDefault).not.toHaveBeenCalled();
expect(setDialogContent).not.toHaveBeenCalled();
});
});

39
spec/frontend/terraform/components/states_table_actions_spec.js
View File

@ -89,17 +89,34 @@ describe('StatesTableActions', () => {
});
describe('when the state is loading', () => {
beforeEach(() => {
return createComponent({
state: {
...defaultProps.state,
loadingActions: true,
},
describe('when lock/unlock is processing', () => {
beforeEach(() => {
return createComponent({
state: {
...defaultProps.state,
loadingLock: true,
},
});
});
it('disables the actions dropdown', () => {
expect(findActionsDropdown().props('disabled')).toBe(true);
});
});
it('disables the actions dropdown', () => {
expect(findActionsDropdown().props('disabled')).toBe(true);
describe('when remove is processing', () => {
beforeEach(() => {
return createComponent({
state: {
...defaultProps.state,
loadingRemove: true,
},
});
});
it('disables the actions dropdown', () => {
expect(findActionsDropdown().props('disabled')).toBe(true);
});
});
});
@ -188,7 +205,8 @@ describe('StatesTableActions', () => {
...unlockedProps.state,
_showDetails: false,
errorMessages: [],
loadingActions: true,
loadingLock: true,
loadingRemove: false,
},
},
// Apollo fields
@ -205,7 +223,8 @@ describe('StatesTableActions', () => {
...unlockedProps.state,
_showDetails: true,
errorMessages: ['There was an error'],
loadingActions: false,
loadingLock: false,
loadingRemove: false,
},
},
// Apollo fields

12
spec/frontend/terraform/components/states_table_spec.js
View File

@ -14,6 +14,8 @@ describe('StatesTable', () => {
_showDetails: true,
errorMessages: ['State 1 has errored'],
name: 'state-1',
loadingLock: false,
loadingRemove: false,
lockedAt: '2020-10-13T00:00:00Z',
lockedByUser: {
name: 'user-1',
@ -25,6 +27,8 @@ describe('StatesTable', () => {
_showDetails: false,
errorMessages: [],
name: 'state-2',
loadingLock: true,
loadingRemove: false,
lockedAt: null,
lockedByUser: null,
updatedAt: '2020-10-10T00:00:00Z',
@ -34,6 +38,8 @@ describe('StatesTable', () => {
_showDetails: false,
errorMessages: [],
name: 'state-3',
loadingLock: true,
loadingRemove: false,
lockedAt: '2020-10-10T00:00:00Z',
lockedByUser: {
name: 'user-2',
@ -63,6 +69,8 @@ describe('StatesTable', () => {
_showDetails: true,
errorMessages: ['State 4 has errored'],
name: 'state-4',
loadingLock: false,
loadingRemove: false,
lockedAt: '2020-10-10T00:00:00Z',
lockedByUser: null,
updatedAt: '2020-10-10T00:00:00Z',
@ -106,8 +114,8 @@ describe('StatesTable', () => {
it.each`
name | toolTipText | locked | lineNumber
${'state-1'} | ${'Locked by user-1 2 days ago'} | ${true} | ${0}
${'state-2'} | ${null} | ${false} | ${1}
${'state-3'} | ${'Locked by user-2 5 days ago'} | ${true} | ${2}
${'state-2'} | ${'Locking state'} | ${false} | ${1}
${'state-3'} | ${'Unlocking state'} | ${false} | ${2}
${'state-4'} | ${'Locked by Unknown User 5 days ago'} | ${true} | ${3}
`(
'displays the name and locked information "$name" for line "$lineNumber"',

36
spec/frontend/terraform/components/terraform_list_spec.js
View File

@ -2,6 +2,7 @@ import { GlAlert, GlBadge, GlKeysetPagination, GlLoadingIcon, GlTab } from '@git
import { createLocalVue, shallowMount } from '@vue/test-utils';
import VueApollo from 'vue-apollo';
import createMockApollo from 'helpers/mock_apollo_helper';
import waitForPromises from 'helpers/wait_for_promises';
import EmptyState from '~/terraform/components/empty_state.vue';
import StatesTable from '~/terraform/components/states_table.vue';
import TerraformList from '~/terraform/components/terraform_list.vue';
@ -27,17 +28,20 @@ describe('TerraformList', () => {
},
};
// Override @client _showDetails
getStatesQuery.getStates.definitions[1].selectionSet.selections[0].directives = [];
// Override @client errorMessages
getStatesQuery.getStates.definitions[1].selectionSet.selections[1].directives = [];
// Override @client loadingActions
getStatesQuery.getStates.definitions[1].selectionSet.selections[2].directives = [];
const mockResolvers = {
TerraformState: {
_showDetails: jest.fn().mockResolvedValue(false),
errorMessages: jest.fn().mockResolvedValue([]),
loadingLock: jest.fn().mockResolvedValue(false),
loadingRemove: jest.fn().mockResolvedValue(false),
},
Mutation: {
addDataToTerraformState: jest.fn().mockResolvedValue({}),
},
};
const statsQueryResponse = queryResponse || jest.fn().mockResolvedValue(apolloQueryResponse);
const apolloProvider = createMockApollo([[getStatesQuery, statsQueryResponse]]);
const apolloProvider = createMockApollo([[getStatesQuery, statsQueryResponse]], mockResolvers);
wrapper = shallowMount(TerraformList, {
localVue,
@ -66,7 +70,8 @@ describe('TerraformList', () => {
id: 'gid://gitlab/Terraform::State/1',
name: 'state-1',
latestVersion: null,
loadingActions: false,
loadingLock: false,
loadingRemove: false,
lockedAt: null,
lockedByUser: null,
updatedAt: null,
@ -77,7 +82,8 @@ describe('TerraformList', () => {
id: 'gid://gitlab/Terraform::State/2',
name: 'state-2',
latestVersion: null,
loadingActions: false,
loadingLock: false,
loadingRemove: false,
lockedAt: null,
lockedByUser: null,
updatedAt: null,
@ -98,7 +104,7 @@ describe('TerraformList', () => {
},
});
return wrapper.vm.$nextTick();
return waitForPromises();
});
it('displays a states tab and count', () => {
@ -126,7 +132,7 @@ describe('TerraformList', () => {
},
});
return wrapper.vm.$nextTick();
return waitForPromises();
});
it('renders the states table without pagination buttons', () => {
@ -146,7 +152,7 @@ describe('TerraformList', () => {
},
});
return wrapper.vm.$nextTick();
return waitForPromises();
});
it('displays a states tab with no count', () => {
@ -164,7 +170,7 @@ describe('TerraformList', () => {
beforeEach(() => {
createWrapper({ terraformStates: null, queryResponse: jest.fn().mockRejectedValue() });
return wrapper.vm.$nextTick();
return waitForPromises();
});
it('displays an alert message', () => {

50
spec/services/integrations/test/project_service_spec.rb
View File

@ -3,6 +3,8 @@
require 'spec_helper'
RSpec.describe Integrations::Test::ProjectService do
include AfterNextHelpers
describe '#execute' do
let_it_be(:project) { create(:project) }
let(:integration) { create(:slack_service, project: project) }
@ -72,9 +74,7 @@ RSpec.describe Integrations::Test::ProjectService do
create(:note, project: project)
allow(Gitlab::DataBuilder::Note).to receive(:build).and_return(sample_data)
allow_next_instance_of(NotesFinder) do |finder|
allow(finder).to receive(:execute).and_return(Note.all)
end
allow_next(NotesFinder).to receive(:execute).and_return(Note.all)
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
@ -92,9 +92,7 @@ RSpec.describe Integrations::Test::ProjectService do
it 'executes integration' do
allow(project).to receive(:issues).and_return([issue])
allow(issue).to receive(:to_hook_data).and_return(sample_data)
allow_next_instance_of(IssuesFinder) do |finder|
allow(finder).to receive(:execute).and_return([issue])
end
allow_next(IssuesFinder).to receive(:execute).and_return([issue])
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
@ -124,9 +122,7 @@ RSpec.describe Integrations::Test::ProjectService do
it 'executes integration' do
allow(merge_request).to receive(:to_hook_data).and_return(sample_data)
allow_next_instance_of(MergeRequestsFinder) do |finder|
allow(finder).to receive(:execute).and_return([merge_request])
end
allow_next(MergeRequestsFinder).to receive(:execute).and_return([merge_request])
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to include(success_result)
@ -135,6 +131,7 @@ RSpec.describe Integrations::Test::ProjectService do
context 'deployment' do
let_it_be(:project) { create(:project, :test_repo) }
let(:deployment) { build(:deployment) }
let(:event) { 'deployment' }
it 'returns error message if not enough data' do
@ -143,16 +140,32 @@ RSpec.describe Integrations::Test::ProjectService do
end
it 'executes integration' do
create(:deployment, project: project)
allow(Gitlab::DataBuilder::Deployment).to receive(:build).and_return(sample_data)
allow_next(DeploymentsFinder).to receive(:execute).and_return([deployment])
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
allow(Gitlab::DataBuilder::Deployment).to receive(:build).and_return(sample_data)
expect(DeploymentsFinder).not_to receive(:new)
expect(project).to receive(:deployments).and_return([deployment])
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
end
end
end
context 'pipeline' do
let(:event) { 'pipeline' }
let(:pipeline) { build(:ci_pipeline) }
it 'returns error message if not enough data' do
expect(integration).not_to receive(:test)
@ -160,12 +173,27 @@ RSpec.describe Integrations::Test::ProjectService do
end
it 'executes integration' do
create(:ci_empty_pipeline, project: project)
allow(Gitlab::DataBuilder::Pipeline).to receive(:build).and_return(sample_data)
allow_next(Ci::PipelinesFinder).to receive(:execute).and_return([pipeline])
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
create(:ci_empty_pipeline, project: project)
allow(Gitlab::DataBuilder::Pipeline).to receive(:build).and_return(sample_data)
expect(Ci::PipelinesFinder).not_to receive(:new)
expect(integration).to receive(:test).with(sample_data).and_return(success_result)
expect(subject).to eq(success_result)
end
end
end
context 'wiki_page' do

70
spec/services/test_hooks/project_service_spec.rb
View File

@ -3,6 +3,8 @@
require 'spec_helper'
RSpec.describe TestHooks::ProjectService do
include AfterNextHelpers
let(:current_user) { create(:user) }
describe '#execute' do
@ -64,9 +66,7 @@ RSpec.describe TestHooks::ProjectService do
create(:note, project: project)
allow(Gitlab::DataBuilder::Note).to receive(:build).and_return(sample_data)
allow_next_instance_of(NotesFinder) do |finder|
allow(finder).to receive(:execute).and_return(Note.all)
end
allow_next(NotesFinder).to receive(:execute).and_return(Note.all)
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
@ -83,9 +83,7 @@ RSpec.describe TestHooks::ProjectService do
it 'executes hook' do
allow(issue).to receive(:to_hook_data).and_return(sample_data)
allow_next_instance_of(IssuesFinder) do |finder|
allow(finder).to receive(:execute).and_return([issue])
end
allow_next(IssuesFinder).to receive(:execute).and_return([issue])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
@ -118,9 +116,7 @@ RSpec.describe TestHooks::ProjectService do
it 'executes hook' do
allow(merge_request).to receive(:to_hook_data).and_return(sample_data)
allow_next_instance_of(MergeRequestsFinder) do |finder|
allow(finder).to receive(:execute).and_return([merge_request])
end
allow_next(MergeRequestsFinder).to receive(:execute).and_return([merge_request])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
@ -130,6 +126,7 @@ RSpec.describe TestHooks::ProjectService do
context 'job_events' do
let(:trigger) { 'job_events' }
let(:trigger_key) { :job_hooks }
let(:ci_job) { build(:ci_build) }
it 'returns error message if not enough data' do
expect(hook).not_to receive(:execute)
@ -137,17 +134,33 @@ RSpec.describe TestHooks::ProjectService do
end
it 'executes hook' do
create(:ci_build, project: project)
allow(Gitlab::DataBuilder::Build).to receive(:build).and_return(sample_data)
allow_next(Ci::JobsFinder).to receive(:execute).and_return([ci_job])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
allow(Gitlab::DataBuilder::Build).to receive(:build).and_return(sample_data)
expect(Ci::JobsFinder).not_to receive(:new)
expect(project).to receive(:builds).and_return([ci_job])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
end
end
context 'pipeline_events' do
let(:trigger) { 'pipeline_events' }
let(:trigger_key) { :pipeline_hooks }
let(:pipeline) { build(:ci_empty_pipeline) }
it 'returns error message if not enough data' do
expect(hook).not_to receive(:execute)
@ -155,12 +168,27 @@ RSpec.describe TestHooks::ProjectService do
end
it 'executes hook' do
create(:ci_empty_pipeline, project: project)
allow(Gitlab::DataBuilder::Pipeline).to receive(:build).and_return(sample_data)
allow_next(Ci::PipelinesFinder).to receive(:execute).and_return([pipeline])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
create(:ci_empty_pipeline, project: project)
allow(Gitlab::DataBuilder::Pipeline).to receive(:build).and_return(sample_data)
expect(Ci::PipelinesFinder).not_to receive(:new)
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
end
end
context 'wiki_page_events' do
@ -192,6 +220,7 @@ RSpec.describe TestHooks::ProjectService do
context 'releases_events' do
let(:trigger) { 'releases_events' }
let(:trigger_key) { :release_hooks }
let(:release) { build(:release) }
it 'returns error message if not enough data' do
expect(hook).not_to receive(:execute)
@ -199,12 +228,27 @@ RSpec.describe TestHooks::ProjectService do
end
it 'executes hook' do
allow(project).to receive(:releases).and_return([Release.new])
allow_any_instance_of(Release).to receive(:to_hook_data).and_return(sample_data)
allow(release).to receive(:to_hook_data).and_return(sample_data)
allow_next(ReleasesFinder).to receive(:execute).and_return([release])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
allow(release).to receive(:to_hook_data).and_return(sample_data)
expect(ReleasesFinder).not_to receive(:new)
expect(project).to receive(:releases).and_return([release])
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
end
end
end
end

30
spec/services/test_hooks/system_service_spec.rb
View File

@ -3,12 +3,12 @@
require 'spec_helper'
RSpec.describe TestHooks::SystemService do
let(:current_user) { create(:user) }
include AfterNextHelpers
describe '#execute' do
let(:project) { create(:project, :repository) }
let_it_be(:project) { create(:project, :repository) }
let(:hook) { create(:system_hook) }
let(:service) { described_class.new(hook, current_user, trigger) }
let(:service) { described_class.new(hook, project.owner, trigger) }
let(:success_result) { { status: :success, http_status: 200, message: 'ok' } }
before do
@ -63,6 +63,9 @@ RSpec.describe TestHooks::SystemService do
context 'merge_requests_events' do
let(:trigger) { 'merge_requests_events' }
let(:trigger_key) { :merge_request_hooks }
let(:merge_requests) { build_list(:merge_request, 2) }
let(:sample_data) { { data: 'sample' } }
it 'returns error message if the user does not have any repository with a merge request' do
expect(hook).not_to receive(:execute)
@ -70,15 +73,24 @@ RSpec.describe TestHooks::SystemService do
end
it 'executes hook' do
trigger_key = :merge_request_hooks
sample_data = { data: 'sample' }
create(:project_member, user: current_user, project: project)
create(:merge_request, source_project: project)
allow_any_instance_of(MergeRequest).to receive(:to_hook_data).and_return(sample_data)
expect(MergeRequest).to receive(:of_projects).and_return(merge_requests)
expect(merge_requests.last).to receive(:to_hook_data).and_return(sample_data)
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
context 'when the reorder feature flag is disabled' do
before do
stub_feature_flags(integrations_test_webhook_reorder: false)
end
it 'executes the old query' do
expect(MergeRequest).to receive(:of_projects).and_return(merge_requests)
expect(merge_requests.first).to receive(:to_hook_data).and_return(sample_data)
expect(hook).to receive(:execute).with(sample_data, trigger_key).and_return(success_result)
expect(service.execute).to include(success_result)
end
end
end
end
end