Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
ae42530b1b
commit
839dad17a1
|
|
@ -4,6 +4,7 @@ import { GlLoadingIcon, GlAlert } from '@gitlab/ui';
|
|||
import { ApolloMutation } from 'vue-apollo';
|
||||
import createFlash from '~/flash';
|
||||
import { fetchPolicies } from '~/lib/graphql';
|
||||
import glFeatureFlagsMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
|
||||
import allVersionsMixin from '../../mixins/all_versions';
|
||||
import Toolbar from '../../components/toolbar/index.vue';
|
||||
import DesignDestroyer from '../../components/design_destroyer.vue';
|
||||
|
|
@ -37,7 +38,7 @@ import {
|
|||
TOGGLE_TODO_ERROR,
|
||||
designDeletionError,
|
||||
} from '../../utils/error_messages';
|
||||
import { trackDesignDetailView } from '../../utils/tracking';
|
||||
import { trackDesignDetailView, usagePingDesignDetailView } from '../../utils/tracking';
|
||||
import { DESIGNS_ROUTE_NAME } from '../../router/constants';
|
||||
import { ACTIVE_DISCUSSION_SOURCE_TYPES, DESIGN_DETAIL_LAYOUT_CLASSLIST } from '../../constants';
|
||||
|
||||
|
|
@ -55,7 +56,7 @@ export default {
|
|||
GlAlert,
|
||||
DesignSidebar,
|
||||
},
|
||||
mixins: [allVersionsMixin],
|
||||
mixins: [allVersionsMixin, glFeatureFlagsMixin()],
|
||||
props: {
|
||||
id: {
|
||||
type: String,
|
||||
|
|
@ -150,7 +151,7 @@ export default {
|
|||
},
|
||||
mounted() {
|
||||
Mousetrap.bind('esc', this.closeDesign);
|
||||
this.trackEvent();
|
||||
this.trackPageViewEvent();
|
||||
|
||||
// Set active discussion immediately.
|
||||
// This will ensure that, if a note is specified in the URL hash,
|
||||
|
|
@ -274,7 +275,7 @@ export default {
|
|||
query: this.$route.query,
|
||||
});
|
||||
},
|
||||
trackEvent() {
|
||||
trackPageViewEvent() {
|
||||
// TODO: This needs to be made aware of referers, or if it's rendered in a different context than a Issue
|
||||
trackDesignDetailView(
|
||||
'issue-design-collection',
|
||||
|
|
@ -282,6 +283,10 @@ export default {
|
|||
this.$route.query.version || this.latestVersionId,
|
||||
this.isLatestVersion,
|
||||
);
|
||||
|
||||
if (this.glFeatures.usageDataDesignAction) {
|
||||
usagePingDesignDetailView();
|
||||
}
|
||||
},
|
||||
updateActiveDiscussion(id, source = ACTIVE_DISCUSSION_SOURCE_TYPES.discussion) {
|
||||
this.$apollo.mutate({
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
import Tracking from '~/tracking';
|
||||
import api from '~/api';
|
||||
|
||||
// Tracking Constants
|
||||
// Snowplow tracking constants
|
||||
const DESIGN_TRACKING_CONTEXT_SCHEMAS = {
|
||||
VIEW_DESIGN_SCHEMA: 'iglu:com.gitlab/design_management_context/jsonschema/1-0-0',
|
||||
};
|
||||
|
|
@ -10,8 +11,14 @@ const DESIGN_TRACKING_EVENTS = {
|
|||
UPDATE_DESIGN: 'update_design',
|
||||
};
|
||||
|
||||
// Usage ping tracking constants
|
||||
const DESIGN_ACTION = 'design_action';
|
||||
|
||||
export const DESIGN_TRACKING_PAGE_NAME = 'projects:issues:design';
|
||||
|
||||
/**
|
||||
* Track "design detail" view in Snowplow
|
||||
*/
|
||||
export function trackDesignDetailView(
|
||||
referer = '',
|
||||
owner = '',
|
||||
|
|
@ -19,6 +26,7 @@ export function trackDesignDetailView(
|
|||
latestVersion = false,
|
||||
) {
|
||||
const eventName = DESIGN_TRACKING_EVENTS.VIEW_DESIGN;
|
||||
|
||||
Tracking.event(DESIGN_TRACKING_PAGE_NAME, eventName, {
|
||||
label: eventName,
|
||||
context: {
|
||||
|
|
@ -40,3 +48,10 @@ export function trackDesignCreate() {
|
|||
export function trackDesignUpdate() {
|
||||
return Tracking.event(DESIGN_TRACKING_PAGE_NAME, DESIGN_TRACKING_EVENTS.UPDATE_DESIGN);
|
||||
}
|
||||
|
||||
/**
|
||||
* Track "design detail" view via usage ping
|
||||
*/
|
||||
export function usagePingDesignDetailView() {
|
||||
api.trackRedisHllUserEvent(DESIGN_ACTION);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ class Projects::IssuesController < Projects::ApplicationController
|
|||
push_frontend_feature_flag(:vue_issuable_sidebar, project.group)
|
||||
push_frontend_feature_flag(:tribute_autocomplete, @project)
|
||||
push_frontend_feature_flag(:vue_issuables_list, project)
|
||||
push_frontend_feature_flag(:usage_data_design_action, project, default_enabled: true)
|
||||
end
|
||||
|
||||
before_action only: :show do
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add primary key to merge_request_context_commit_diff_files
|
||||
merge_request: 49024
|
||||
author:
|
||||
type: changed
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Capture design detail views via usage ping
|
||||
merge_request: 46751
|
||||
author:
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add link in Access Request API
|
||||
merge_request: 48081
|
||||
author: jimcser
|
||||
type: fixed
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
name: usage_data_design_action
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46626
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/287630
|
||||
milestone: '13.7'
|
||||
type: development
|
||||
group: group::knowledge
|
||||
default_enabled: true
|
||||
|
|
@ -128,6 +128,7 @@ class ObjectStoreSettings
|
|||
|
||||
if section['enabled'] && target_config['bucket'].blank?
|
||||
missing_bucket_for(store_type)
|
||||
next
|
||||
end
|
||||
|
||||
# If a storage type such as Pages defines its own connection and does not
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddPrimaryKeyToMergeRequestContextCommitDiffFiles < ActiveRecord::Migration[6.0]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
DOWNTIME = false
|
||||
|
||||
def up
|
||||
execute(<<~SQL)
|
||||
DELETE FROM merge_request_context_commit_diff_files
|
||||
WHERE merge_request_context_commit_id IS NULL;
|
||||
|
||||
DELETE FROM merge_request_context_commit_diff_files df1
|
||||
USING merge_request_context_commit_diff_files df2
|
||||
WHERE df1.ctid < df2.ctid
|
||||
AND df1.merge_request_context_commit_id = df2.merge_request_context_commit_id
|
||||
AND df1.relative_order = df2.relative_order;
|
||||
|
||||
ALTER TABLE merge_request_context_commit_diff_files
|
||||
ADD CONSTRAINT merge_request_context_commit_diff_files_pkey PRIMARY KEY (merge_request_context_commit_id, relative_order);
|
||||
SQL
|
||||
end
|
||||
|
||||
def down
|
||||
execute(<<~SQL)
|
||||
ALTER TABLE merge_request_context_commit_diff_files
|
||||
DROP CONSTRAINT merge_request_context_commit_diff_files_pkey,
|
||||
ALTER COLUMN merge_request_context_commit_id DROP NOT NULL
|
||||
SQL
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class RemoveRedundantIndexOnMergeRequestContextCommitDiffFiles < ActiveRecord::Migration[6.0]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
DOWNTIME = false
|
||||
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
remove_concurrent_index_by_name :merge_request_context_commit_diff_files, 'idx_mr_cc_diff_files_on_mr_cc_id'
|
||||
end
|
||||
|
||||
def down
|
||||
# no-op: this index is not tracked in structure.sql, and is redundant due to idx_mr_cc_diff_files_on_mr_cc_id_and_sha
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
926f54b5756fa9495e71f2340823418b5679195d5720212dddda0d0c6396629e
|
||||
|
|
@ -0,0 +1 @@
|
|||
696c1d9f8cc90337549530e129e6abf4429d218f151cefaacacacb6e3f33d1c7
|
||||
|
|
@ -13695,7 +13695,7 @@ CREATE TABLE merge_request_context_commit_diff_files (
|
|||
old_path text NOT NULL,
|
||||
diff text,
|
||||
"binary" boolean,
|
||||
merge_request_context_commit_id bigint
|
||||
merge_request_context_commit_id bigint NOT NULL
|
||||
);
|
||||
|
||||
CREATE TABLE merge_request_context_commits (
|
||||
|
|
@ -19550,6 +19550,9 @@ ALTER TABLE ONLY merge_request_blocks
|
|||
ALTER TABLE ONLY merge_request_cleanup_schedules
|
||||
ADD CONSTRAINT merge_request_cleanup_schedules_pkey PRIMARY KEY (merge_request_id);
|
||||
|
||||
ALTER TABLE ONLY merge_request_context_commit_diff_files
|
||||
ADD CONSTRAINT merge_request_context_commit_diff_files_pkey PRIMARY KEY (merge_request_context_commit_id, relative_order);
|
||||
|
||||
ALTER TABLE ONLY merge_request_context_commits
|
||||
ADD CONSTRAINT merge_request_context_commits_pkey PRIMARY KEY (id);
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
#
|
||||
# For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
|
||||
extends: substitution
|
||||
message: "NOTE: and TIP: alert boxes must be of the format 'NOTE: **Note:**' or 'TIP: **Tip:**"
|
||||
message: "NOTE: and TIP: alert boxes must be of the format 'NOTE:' or 'TIP: **Tip:**"
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#alert-boxes
|
||||
level: warning
|
||||
nonword: true
|
||||
|
|
|
|||
407
doc/README.md
407
doc/README.md
|
|
@ -23,14 +23,14 @@ Here you can access the complete documentation for GitLab, the single applicatio
|
|||
|
||||
No matter how you use GitLab, we have documentation for you.
|
||||
|
||||
| Essential documentation | Essential documentation |
|
||||
|:------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------|
|
||||
| [**User documentation**](user/index.md)<br>Discover features and concepts for GitLab users. | [**Administrator documentation**](administration/index.md)<br/>Everything GitLab self-managed administrators need to know. |
|
||||
| [**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 automation and 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's reference architectures |
|
||||
| [**GitLab releases**](https://about.gitlab.com/releases/)<br/>What's new in GitLab. | |
|
||||
| Essential documentation | Essential documentation |
|
||||
|:---------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------|
|
||||
| [**User documentation**](user/index.md)<br>Discover features and concepts for GitLab users. | [**Administrator documentation**](administration/index.md)<br/>Everything GitLab self-managed administrators need to know. |
|
||||
| [**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's reference architectures |
|
||||
| [**GitLab releases**](https://about.gitlab.com/releases/)<br/>What's new in GitLab. | |
|
||||
|
||||
## Popular topics
|
||||
|
||||
|
|
@ -53,349 +53,10 @@ Have a look at some of our most popular topics:
|
|||
## The entire DevOps lifecycle
|
||||
|
||||
GitLab is the first single application for software development, security,
|
||||
and operations that enables [Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/),
|
||||
making the software lifecycle faster and radically improving the speed of business.
|
||||
and operations that enables [Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/).
|
||||
GitLab makes the software lifecycle faster and radically improves the speed of business.
|
||||
|
||||
GitLab provides solutions for [each of the stages of the DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/):
|
||||
|
||||
|
||||
|
||||
GitLab is like a top-of-the-line kitchen for making software. As the executive
|
||||
chef, you decide what software you want to serve. Using your recipe, GitLab handles
|
||||
all the prep work, cooking, and delivery, so you can turn around orders faster
|
||||
than ever.
|
||||
|
||||
The following sections provide links to documentation for each DevOps stage:
|
||||
|
||||
| DevOps stage | Documentation for |
|
||||
|:------------------------|:------------------------------------------------------------|
|
||||
| [Manage](#manage) | Statistics and analytics features. |
|
||||
| [Plan](#plan) | Project planning and management features. |
|
||||
| [Create](#create) | Source code, data creation, and management features. |
|
||||
| [Verify](#verify) | Testing, code quality, and continuous integration features. |
|
||||
| [Package](#package) | Docker container registry. |
|
||||
| [Secure](#secure) | Security capability features. |
|
||||
| [Release](#release) | Application release and delivery features. |
|
||||
| [Configure](#configure) | Application and infrastructure configuration tools. |
|
||||
| [Monitor](#monitor) | Application monitoring and metrics features. |
|
||||
| [Defend](#defend) | Protection against security intrusions. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Manage
|
||||
|
||||
GitLab provides statistics and insights into ways you can maximize the value of GitLab in your organization.
|
||||
|
||||
The following documentation relates to the DevOps **Manage** stage:
|
||||
|
||||
| Manage topics | Description |
|
||||
|:--------------------------------------------------------------------------------------|:---------------------------------------------------------------------------|
|
||||
| [Authentication and<br/>Authorization](administration/auth/README.md) **(CORE ONLY)** | Supported authentication and authorization providers. |
|
||||
| [GitLab Value Stream Analytics](user/analytics/value_stream_analytics.md) | Measure the time it takes to go from an [idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab) for each project you have. |
|
||||
| [Instance-level analytics](user/admin_area/analytics/index.md) | Discover statistics on how many GitLab features you use and user activity. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Plan
|
||||
|
||||
Whether you use Waterfall, Agile, or Conversational Development, GitLab streamlines your collaborative workflows.
|
||||
|
||||
Visualize, prioritize, coordinate, and track your progress your way with GitLab’s flexible project
|
||||
management tools.
|
||||
|
||||
The following documentation relates to the DevOps **Plan** stage:
|
||||
|
||||
| Plan topics | Description |
|
||||
|:-----------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Burndown charts](user/project/milestones/burndown_and_burnup_charts.md) **(STARTER)** | Watch your project's progress throughout a specific milestone. |
|
||||
| [Discussions](user/discussions/index.md) | Threads, comments, and resolvable threads in issues, commits, and merge requests. |
|
||||
| [Due dates](user/project/issues/due_dates.md) | Keep track of issue deadlines. |
|
||||
| [Epics](user/group/epics/index.md) **(ULTIMATE)** | Tracking groups of issues that share a theme. |
|
||||
| [Issues](user/project/issues/index.md), including [confidential issues](user/project/issues/confidential_issues.md),<br/>[issue and merge request templates](user/project/description_templates.md),<br/>and [moving issues](user/project/issues/managing_issues.md#moving-issues) | Project issues and restricting access to issues as well as creating templates for submitting new issues and merge requests. Also, moving issues between projects. |
|
||||
| [Labels](user/project/labels.md) | Categorize issues or merge requests with descriptive labels. |
|
||||
| [Milestones](user/project/milestones/index.md) | Set milestones for delivery of issues and merge requests, with optional due date. |
|
||||
| [Project Issue Board](user/project/issue_board.md) | Display issues on a Scrum or Kanban board. |
|
||||
| [Quick Actions](user/project/quick_actions.md) | Shortcuts for common actions on issues or merge requests, replacing the need to click buttons or use dropdowns in GitLab's UI. |
|
||||
| [Related issues](user/project/issues/related_issues.md) | Create a relationship between issues. |
|
||||
| [Requirements Management](user/project/requirements/index.md) **(ULTIMATE)** | Check your products against a set of criteria. |
|
||||
| [Roadmap](user/group/roadmap/index.md) **(ULTIMATE)** | Visualize epic timelines. |
|
||||
| [Service Desk](user/project/service_desk.md) | A simple way to allow people to create issues in your GitLab instance without needing their own user account. |
|
||||
| [Time Tracking](user/project/time_tracking.md) | Track time spent on issues and merge requests. |
|
||||
| [To-Do list](user/todos.md) | Keep track of work requiring attention with a chronological list displayed on a simple dashboard. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Create
|
||||
|
||||
Consolidate source code into a single [distributed version control system](https://en.wikipedia.org/wiki/Distributed_version_control)
|
||||
that’s easily managed and controlled without disrupting your workflow.
|
||||
|
||||
GitLab repositories come complete with branching tools and access
|
||||
controls, providing a scalable, single source of truth for collaborating
|
||||
on projects and code.
|
||||
|
||||
The following documentation relates to the DevOps **Create** stage:
|
||||
|
||||
#### Projects and groups
|
||||
|
||||
| Create topics - Projects and Groups | Description |
|
||||
|:-----------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------|
|
||||
| [Advanced search](user/search/advanced_global_search.md) **(STARTER)** | Leverage Elasticsearch for faster, more advanced code search across your entire GitLab instance. |
|
||||
| [Advanced syntax search](user/search/advanced_search_syntax.md) **(STARTER)** | Use advanced queries for more targeted search results. |
|
||||
| [Contribution analytics](user/group/contribution_analytics/index.md) **(STARTER)** | See detailed statistics of group contributors. |
|
||||
| [Create](gitlab-basics/create-project.md) and [fork](gitlab-basics/fork-project.md) projects, and<br/>[import and export projects<br/>between instances](user/project/settings/import_export.md) | Create, duplicate, and move projects. |
|
||||
| [File locking](user/project/file_lock.md) **(PREMIUM)** | Lock files to avoid merge conflicts. |
|
||||
| [GitLab Pages](user/project/pages/index.md) | Build, test, and deploy your static website with GitLab Pages. |
|
||||
| [Groups](user/group/index.md) and [Subgroups](user/group/subgroups/index.md) | Organize your projects in groups. |
|
||||
| [Issue analytics](user/group/issues_analytics/index.md) **(PREMIUM)** | Check how many issues were created per month. |
|
||||
| [Merge Request analytics](user/analytics/merge_request_analytics.md) **(PREMIUM)** | Check your throughput productivity - how many merge requests were merged per month. |
|
||||
| [Projects](user/project/index.md), including [project access](public_access/public_access.md)<br/>and [settings](user/project/settings/index.md) | Host source code, and control your project's visibility and set configuration. |
|
||||
| [Search through GitLab](user/search/index.md) | Search for issues, merge requests, projects, groups, and to-dos. |
|
||||
| [Snippets](user/snippets.md) | Snippets allow you to create little bits of code. |
|
||||
| [Web IDE](user/project/web_ide/index.md) | Edit files within GitLab's user interface. |
|
||||
| [Static Site Editor](user/project/static_site_editor/index.md) | Edit content on static websites. |
|
||||
| [Wikis](user/project/wiki/index.md) | Enhance your repository documentation with built-in wikis. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
#### Repositories
|
||||
|
||||
| Create topics - Repositories | Description |
|
||||
|:-----------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------|
|
||||
| [Branches](user/project/repository/branches/index.md) and the [default branch](user/project/repository/branches/index.md#default-branch) | How to use branches in GitLab. |
|
||||
| [Commits](user/project/repository/index.md#commits) and [signing commits](user/project/repository/gpg_signed_commits/index.md) | Work with commits, and use GPG to sign your commits. |
|
||||
| [Create branches](user/project/repository/web_editor.md#create-a-new-branch), [create](user/project/repository/web_editor.md#create-a-file)<br/>and [upload](user/project/repository/web_editor.md#upload-a-file) files, and [create directories](user/project/repository/web_editor.md#create-a-directory) | Create branches, create and upload files, and create directories within GitLab. |
|
||||
| [Delete merged branches](user/project/repository/branches/index.md#delete-merged-branches) | Bulk delete branches after their changes are merged. |
|
||||
| [File templates](user/project/repository/web_editor.md#template-dropdowns) | File templates for common files. |
|
||||
| [Files](user/project/repository/index.md#files) | Files management. |
|
||||
| [Jupyter Notebook files](user/project/repository/jupyter_notebooks/index.md#jupyter-notebook-files) | GitLab's support for `.ipynb` files. |
|
||||
| [Protected branches](user/project/protected_branches.md) | Use protected branches. |
|
||||
| [Push rules](push_rules/push_rules.md) **(STARTER)** | Additional control over pushes to your projects. |
|
||||
| [Repositories](user/project/repository/index.md) | Manage source code repositories in GitLab's user interface. |
|
||||
| [Repository mirroring](user/project/repository/repository_mirroring.md) **(STARTER)** | Push to or pull from repositories outside of GitLab |
|
||||
| [Start a merge request](user/project/repository/web_editor.md#tips) | Start merge request when committing via GitLab's user interface. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
#### Merge requests
|
||||
|
||||
| Create topics - Merge Requests | Description |
|
||||
|:---------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Checking out merge requests locally](user/project/merge_requests/reviewing_and_managing_merge_requests.md#checkout-merge-requests-locally-through-the-head-ref) | Tips for working with merge requests locally. |
|
||||
| [Cherry-picking](user/project/merge_requests/cherry_pick_changes.md) | Use GitLab for cherry-picking changes. |
|
||||
| [Merge request thread resolution](user/discussions/index.md#moving-a-single-thread-to-a-new-issue) | Resolve threads, move threads in a merge request to an issue, and only allow merge requests to be merged if all threads are resolved. |
|
||||
| [Merge requests](user/project/merge_requests/index.md) | Merge request management. |
|
||||
| [Draft merge requests](user/project/merge_requests/work_in_progress_merge_requests.md) | Prevent merges of draft merge requests. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
#### Integration and Automation
|
||||
|
||||
| Create topics - Integration and Automation | Description |
|
||||
|:----------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|
|
||||
| [GitLab REST API](api/README.md) | Integrate with GitLab using our REST API. |
|
||||
| [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
|
||||
| [GitLab integrations](integration/README.md) | Integrate with multiple third-party services with GitLab to allow external issue trackers and external authentication. |
|
||||
| [GitLab Webhooks](user/project/integrations/webhooks.md) | Let GitLab notify you when new code has been pushed to your project. |
|
||||
| [Jira Development Panel](integration/jira_development_panel.md) | See GitLab information in the Jira Development Panel. |
|
||||
| [Integrations](user/project/integrations/overview.md) | Integrate a project with external services, such as CI and chat. |
|
||||
| [Trello Power-Up](integration/trello_power_up.md) | Integrate with GitLab's Trello Power-Up. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Verify
|
||||
|
||||
Spot errors sooner, improve security and shorten feedback cycles with built-in
|
||||
static code analysis, code testing, code quality, dependency checking, and Review
|
||||
Apps. Customize your approval workflow controls, automatically test the quality
|
||||
of your code, and spin up a staging environment for every code change.
|
||||
|
||||
GitLab Continuous Integration is the most popular next generation testing system that
|
||||
scales to run your tests faster.
|
||||
|
||||
The following documentation relates to the DevOps **Verify** stage:
|
||||
|
||||
| Verify topics | Description |
|
||||
|:-----------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------|
|
||||
| [Code Quality reports](user/project/merge_requests/code_quality.md) | Analyze source code quality. |
|
||||
| [GitLab CI/CD](ci/README.md) | Explore the features and capabilities of Continuous Integration with GitLab. |
|
||||
| [Unit test reports](ci/unit_test_reports.md) | Display Unit test reports on merge requests. |
|
||||
| [Multi-project pipelines](ci/multi_project_pipelines.md) **(PREMIUM)** | Visualize entire pipelines that span multiple projects, including all cross-project inter-dependencies. |
|
||||
| [Pipeline graphs](ci/pipelines/index.md#visualize-pipelines) | Visualize builds. |
|
||||
| [Review Apps](ci/review_apps/index.md) | Preview changes to your application right from a merge request. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Package
|
||||
|
||||
GitLab Packages allows organizations to use GitLab as a private repository
|
||||
for a variety of common package managers. Users are able to build and publish
|
||||
packages, which can be consumed as a dependency in downstream projects.
|
||||
|
||||
The following documentation relates to the DevOps **Package** stage:
|
||||
|
||||
| Package topics | Description |
|
||||
|:----------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Container Registry](user/packages/container_registry/index.md) | The GitLab Container Registry enables every project in GitLab to have its own space to store [Docker](https://www.docker.com/) images. |
|
||||
| [Dependency Proxy](user/packages/dependency_proxy/index.md) | The GitLab Dependency Proxy sets up a local proxy for frequently used upstream images/packages. |
|
||||
| [Package Registry](user/packages/package_registry/index.md) | Use GitLab as a private or public registry for a variety of common package managers, including [NPM](user/packages/npm_registry/index.md), [Maven](user/packages/maven_repository/index.md), [PyPI](user/packages/pypi_repository/index.md), and others. You can also store generic files. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Secure
|
||||
|
||||
Check your application for security vulnerabilities that may lead to unauthorized access, data
|
||||
leaks, or denial of service. GitLab can perform static and dynamic tests on your application's code,
|
||||
looking for known flaws and reporting them in the merge request. You can then fix flaws prior to
|
||||
merge. Security teams can use dashboards to get a high-level view on projects and groups, and start
|
||||
remediation processes when needed.
|
||||
|
||||
The following documentation relates to the DevOps **Secure** stage:
|
||||
|
||||
| Secure topics | Description |
|
||||
|:------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|
|
||||
| [Compliance Dashboard](user/compliance/compliance_dashboard/index.md) **(ULTIMATE)** | View the most recent Merge Request activity in a group. |
|
||||
| [Container Scanning](user/application_security/container_scanning/index.md) **(ULTIMATE)** | Use Clair to scan Docker images for known vulnerabilities. |
|
||||
| [Dependency List](user/application_security/dependency_list/index.md) **(ULTIMATE)** | View your project's dependencies and their known vulnerabilities. |
|
||||
| [Dependency Scanning](user/application_security/dependency_scanning/index.md) **(ULTIMATE)** | Analyze your dependencies for known vulnerabilities. |
|
||||
| [Dynamic Application Security Testing (DAST)](user/application_security/dast/index.md) **(ULTIMATE)** | Analyze running web applications for known vulnerabilities. |
|
||||
| [Group Security Dashboard](user/application_security/security_dashboard/index.md#group-security-dashboard) **(ULTIMATE)** | View vulnerabilities in all the projects in a group and its subgroups. |
|
||||
| [Instance Security Center](user/application_security/security_dashboard/index.md#instance-security-center) **(ULTIMATE)** | View vulnerabilities in all the projects you're interested in. |
|
||||
| [License Compliance](user/compliance/license_compliance/index.md) **(ULTIMATE)** | Search your project's dependencies for their licenses. |
|
||||
| [Pipeline Security](user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)** | View the security reports for your project's pipelines. |
|
||||
| [Project Security Dashboard](user/application_security/security_dashboard/index.md#project-security-dashboard) **(ULTIMATE)** | View the latest security reports for your project. |
|
||||
| [Static Application Security Testing (SAST)](user/application_security/sast/index.md) **(ULTIMATE)** | Analyze source code for known vulnerabilities. |
|
||||
|
||||
### Release
|
||||
|
||||
Spend less time configuring your tools, and more time creating. Whether you’re
|
||||
deploying to one server or thousands, build, test, and release your code
|
||||
confidently and securely with GitLab’s built-in Continuous Delivery and Deployment.
|
||||
|
||||
The following documentation relates to the DevOps **Release** stage:
|
||||
|
||||
| Release topics | Description |
|
||||
|:---------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Auto Deploy](topics/autodevops/stages.md#auto-deploy) | Configure GitLab for the deployment of your application. |
|
||||
| [Canary Deployments](user/project/canary_deployments.md) **(PREMIUM)** | Employ a popular CI strategy where a small portion of the fleet is updated to the new version first. |
|
||||
| [Deploy Boards](user/project/deploy_boards.md) **(PREMIUM)** | View the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. |
|
||||
| [Environments and deployments](ci/environments/index.md) | With environments, you can control the continuous deployment of your software within GitLab. |
|
||||
| [Environment-specific variables](ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) | Limit the scope of variables to specific environments. |
|
||||
| [GitLab CI/CD](ci/README.md) | Explore the features and capabilities of Continuous Deployment and Delivery with GitLab. |
|
||||
| [GitLab Pages](user/project/pages/index.md) | Build, test, and deploy a static site directly from GitLab. |
|
||||
| [Protected runners](ci/runners/README.md#prevent-runners-from-revealing-sensitive-information) | Select Runners to only pick jobs for protected branches and tags. |
|
||||
| [Schedule pipelines](ci/pipelines/schedules.md) | Execute pipelines on a schedule. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Configure
|
||||
|
||||
Automate your entire workflow from build to deploy and monitoring with GitLab
|
||||
Auto DevOps. Best practice templates help get you started with minimal to zero
|
||||
configuration. Then customize everything from buildpacks to CI/CD.
|
||||
|
||||
The following documentation relates to the DevOps **Configure** stage:
|
||||
|
||||
| Configure topics | Description |
|
||||
|:----------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|
|
||||
| [Auto DevOps](topics/autodevops/index.md) | Automatically employ a complete DevOps lifecycle. |
|
||||
| [Create Kubernetes clusters](user/project/clusters/add_remove_clusters.md#create-new-cluster) | Use Kubernetes and GitLab. |
|
||||
| [Executable Runbooks](user/project/clusters/runbooks/index.md) | Documented procedures that explain how to carry out particular processes. |
|
||||
| [GitLab ChatOps](ci/chatops/README.md) | Interact with CI/CD jobs through chat services. |
|
||||
| [Installing applications](user/project/clusters/index.md#installing-applications) | Install Helm charts such as Ingress and Prometheus on Kubernetes. |
|
||||
| [Mattermost slash commands](user/project/integrations/mattermost_slash_commands.md) | Enable and use slash commands from within Mattermost. |
|
||||
| [Multiple Kubernetes clusters](user/project/clusters/index.md#multiple-kubernetes-clusters) | Associate more than one Kubernetes clusters to your project. |
|
||||
| [Protected variables](ci/variables/README.md#protect-a-custom-variable) | Restrict variables to protected branches and tags. |
|
||||
| [Serverless](user/project/clusters/serverless/index.md) | Run serverless workloads on Kubernetes. |
|
||||
| [Slack slash commands](user/project/integrations/slack_slash_commands.md) | Enable and use slash commands from within Slack. |
|
||||
| [Manage your infrastructure with Terraform](user/infrastructure/index.md) | Manage your infrastructure as you run your CI/CD pipeline. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Monitor
|
||||
|
||||
Ensure your applications are always responsive and available.
|
||||
|
||||
GitLab collects and displays performance metrics for deployed applications so you can know in an
|
||||
instant how code changes impact your production environment.
|
||||
|
||||
The following documentation relates to the DevOps **Monitor** stage:
|
||||
|
||||
| Monitor topics | Description |
|
||||
|:------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [GitLab Performance Monitoring](administration/monitoring/performance/index.md) **(CORE ONLY)** | Use Prometheus and Grafana to monitor the performance of your GitLab instance. |
|
||||
| [GitLab Prometheus](administration/monitoring/prometheus/index.md) **(CORE ONLY)** | Configure the bundled Prometheus to collect various metrics from your GitLab instance. |
|
||||
| [Health check](user/admin_area/monitoring/health_check.md) | GitLab provides liveness and readiness probes to indicate service health and reachability to required services. |
|
||||
| [Prometheus project integration](user/project/integrations/prometheus.md) | Configure the Prometheus integration per project and monitor your CI/CD environments. |
|
||||
| [Prometheus metrics](user/project/integrations/prometheus_library/index.md) | Let Prometheus collect metrics from various services, like Kubernetes, NGINX, NGINX Ingress controller, HAProxy, and Amazon Cloud Watch. |
|
||||
| [Incident management](operations/incident_management/index.md) | Use GitLab to help you better respond to incidents that may occur in your systems. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Defend
|
||||
|
||||
GitLab Defend enables organizations to proactively protect cloud-native environments by providing
|
||||
context-aware technologies to reduce overall security risk. Defend is a natural extension of your
|
||||
existing operation's practices and provides security visibility across the entire DevSecOps
|
||||
lifecycle. This visibility empowers your organization to apply DevSecOps best practices from the
|
||||
first line of code written and extends all the way through to greater monitoring and protection for
|
||||
your applications that are deployed in production.
|
||||
|
||||
The following documentation relates to the DevOps **Defend** stage:
|
||||
|
||||
| Defend topics | Description |
|
||||
|:---------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|
|
||||
| [Web Application Firewall with ModSecurity](user/compliance/compliance_dashboard/index.md) | Filter, monitor, and block HTTP traffic to and from a web application. |
|
||||
| [Container host security](user/clusters/applications.md#install-falco-using-gitlab-cicd) | Detect and respond to security threats at the Kubernetes, network, and host level. |
|
||||
| [Container network security](user/clusters/applications.md#install-cilium-using-gitlab-cicd) | Detect and block unauthorized network traffic between pods and to/from the internet. |
|
||||
GitLab provides solutions for [each of the stages of the DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/).
|
||||
|
||||
## New to Git and GitLab?
|
||||
|
||||
|
|
@ -411,12 +72,6 @@ We have the following documentation to rapidly uplift your GitLab knowledge:
|
|||
| [Auto DevOps](topics/autodevops/index.md) | Learn more about GitLab's Auto DevOps. |
|
||||
| [GitLab Markdown](user/markdown.md) | GitLab's advanced formatting system (GitLab Flavored Markdown) |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### User account
|
||||
|
||||
Learn more about GitLab account management:
|
||||
|
|
@ -428,12 +83,6 @@ Learn more about GitLab account management:
|
|||
| [Profile settings](user/profile/index.md#profile-settings) | Manage your profile settings, two factor authentication, and more. |
|
||||
| [User permissions](user/permissions.md) | Learn what each role in a project can do. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
### Git and GitLab
|
||||
|
||||
Learn more about using Git, and using Git with GitLab:
|
||||
|
|
@ -444,12 +93,6 @@ Learn more about using Git, and using Git with GitLab:
|
|||
| [Git cheat sheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf) | Download a PDF describing the most used Git operations. |
|
||||
| [GitLab Flow](topics/gitlab_flow.md) | Explore the best of Git with the GitLab Flow strategy. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
## Coming to GitLab from another platform
|
||||
|
||||
If you are coming to GitLab from another platform, the following information is useful:
|
||||
|
|
@ -459,27 +102,15 @@ If you are coming to GitLab from another platform, the following information is
|
|||
| [Importing to GitLab](user/project/import/index.md) | Import your projects from GitHub, Bitbucket, GitLab.com, FogBugz, and SVN into GitLab. |
|
||||
| [Migrating from SVN](user/project/import/svn.md) | Convert a SVN repository to Git and GitLab. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
## Build an integration with GitLab
|
||||
|
||||
There are many ways to integrate with GitLab, including:
|
||||
|
||||
| Topic | Description |
|
||||
|:-----------------------------------------------------------|:-----------------------------------------------|
|
||||
| [GitLab REST API](api/README.md) | Integrate with GitLab using our REST API. |
|
||||
| [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
|
||||
| [Integrations and automation](#integration-and-automation) | All GitLab integration and automation options. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
| Topic | Description |
|
||||
|:-------------------------------------------|:---------------------------------------------|
|
||||
| [GitLab REST API](api/README.md) | Integrate with GitLab using our REST API. |
|
||||
| [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
|
||||
| [Integrations](integration/README.md) | Integrations with third-party products. |
|
||||
|
||||
## Contributing to GitLab
|
||||
|
||||
|
|
@ -493,9 +124,3 @@ Learn how to contribute to GitLab with the following resources:
|
|||
| [Development](development/README.md) | How to contribute to GitLab development. |
|
||||
| [Legal](legal/README.md) | Contributor license agreements. |
|
||||
| [Writing documentation](development/documentation/index.md) | How to contribute to GitLab Docs. |
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#overview">
|
||||
Back to Overview <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
</a>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ Impersonation is where an administrator uses credentials to perform an action as
|
|||
|
||||
### Group events **(STARTER)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You need Owner [permissions](../user/permissions.md) to view the group Audit Events page.
|
||||
|
||||
To view a group's audit events, navigate to **Group > Settings > Audit Events**.
|
||||
|
|
@ -74,7 +74,7 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
|
|||
|
||||
### Project events **(STARTER)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You need Maintainer [permissions](../user/permissions.md) or higher to view the project Audit Events page.
|
||||
|
||||
To view a project's audit events, navigate to **Project > Settings > Audit Events**.
|
||||
|
|
|
|||
|
|
@ -36,5 +36,5 @@ providers:
|
|||
- [Smartcard](smartcard.md) **(PREMIUM ONLY)**
|
||||
- [Twitter](../../integration/twitter.md)
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
UltraAuth has removed their software which supports OmniAuth integration. We have therefore removed all references to UltraAuth integration.
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ JWT will provide you with a secret key for you to use.
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For more information on each configuration option refer to
|
||||
the [OmniAuth JWT usage documentation](https://github.com/mbleigh/omniauth-jwt#usage).
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ There is a Rake task to check LDAP configuration. After configuring LDAP
|
|||
using the documentation below, see [LDAP check Rake task](../../raketasks/check.md#ldap-check)
|
||||
for information on the LDAP check Rake task.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The `encryption` value `simple_tls` corresponds to 'Simple TLS' in the LDAP
|
||||
library. `start_tls` corresponds to StartTLS, not to be confused with regular TLS.
|
||||
Normally, if you specify `simple_tls` it is on port 636, while `start_tls` (StartTLS)
|
||||
|
|
@ -553,7 +553,7 @@ administrators. Specify a group CN for `admin_group` and all members of the
|
|||
LDAP group will be given administrator privileges. The configuration looks
|
||||
like the following.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Administrators are not synced unless `group_base` is also
|
||||
specified alongside `admin_group`. Also, only specify the CN of the admin
|
||||
group, as opposed to the full DN.
|
||||
|
|
@ -615,7 +615,7 @@ By default, GitLab runs a group sync process every hour, on the hour.
|
|||
The values shown are in cron format. If needed, you can use a
|
||||
[Crontab Generator](http://www.crontabgenerator.com).
|
||||
|
||||
CAUTION: **Important:**
|
||||
WARNING:
|
||||
Do not start the sync process too frequently as this
|
||||
could lead to multiple syncs running concurrently. This is primarily a concern
|
||||
for installations with a large number of LDAP users. Please review the
|
||||
|
|
|
|||
|
|
@ -378,7 +378,7 @@ GitLab syncs the `admin_group`.
|
|||
|
||||
#### Sync all groups **(STARTER ONLY)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
To sync all groups manually when debugging is unnecessary, [use the Rake
|
||||
task](../../raketasks/ldap.md#run-a-group-sync) instead.
|
||||
|
||||
|
|
@ -429,7 +429,7 @@ and more DNs may be added, or existing entries modified, based on additional
|
|||
LDAP group lookups. The very last occurrence of this entry should indicate
|
||||
exactly which users GitLab believes should be added to the group.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
|
||||
and 50 is 'Owner'.
|
||||
|
||||
|
|
@ -673,7 +673,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
|
|||
|
||||
### Rails console
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
It is very easy to create, read, modify, and destroy data with the rails
|
||||
console. Be sure to run commands exactly as listed.
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ The OpenID Connect will provide you with a client details and secret for you to
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For more information on each configuration option refer to the [OmniAuth OpenID Connect usage documentation](https://github.com/m0n9oose/omniauth_openid_connect#usage)
|
||||
and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
|
||||
|
||||
|
|
|
|||
|
|
@ -158,7 +158,7 @@ You might want to try this out on an incognito browser window.
|
|||
|
||||
## Configuring groups
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Make sure the groups exist and are assigned to the Okta app.
|
||||
|
||||
You can take a look of the [SAML documentation](../../integration/saml.md#saml-groups) on configuring groups.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ GitLab supports two authentication methods:
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/726) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental feature.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Smartcard authentication against local databases may change or be removed completely in future
|
||||
releases.
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ Certificate:
|
|||
Smartcards with X.509 certificates using SAN extensions can be used to authenticate
|
||||
with GitLab.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This is an experimental feature. Smartcard authentication against local databases may
|
||||
change or be removed completely in future releases.
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ attribute. As a prerequisite, you must use an LDAP server that:
|
|||
client_certificate_required_port: 3443
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Assign a value to at least one of the following variables:
|
||||
`client_certificate_required_host` or `client_certificate_required_port`.
|
||||
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ queried over UDP. To overcome this issue, you can use TCP for querying by settin
|
|||
|
||||
### Forking
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Starting with GitLab 13.0, Puma is the default web server used in GitLab
|
||||
all-in-one package based installations as well as GitLab Helm chart deployments.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: reference, howto
|
|||
|
||||
You can use an external service for validating a pipeline before it's created.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
This is an experimental feature and subject to change without notice.
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ error, it's very important that you [**provide feedback**](https://gitlab.com/gi
|
|||
as possible so we can improve or fix it while behind a flag. When you upgrade
|
||||
GitLab to an earlier version, the feature flag status may change.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Features deployed behind feature flags may not be ready for
|
||||
production use. However, disabling features behind flags that were deployed
|
||||
enabled by default may also present a risk. If they're enabled, we recommend
|
||||
|
|
|
|||
|
|
@ -13,12 +13,12 @@ type: reference
|
|||
With custom file hooks, GitLab administrators can introduce custom integrations
|
||||
without modifying GitLab's source code.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Instead of writing and supporting your own file hook you can make changes
|
||||
directly to the GitLab source code and contribute back upstream. This way we can
|
||||
ensure functionality is preserved across versions and covered by tests.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
File hooks must be configured on the filesystem of the GitLab server. Only GitLab
|
||||
server administrators will be able to complete these tasks. Explore
|
||||
[system hooks](../system_hooks/system_hooks.md) or [webhooks](../user/project/integrations/webhooks.md) as an option if you do not have filesystem access.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ type: howto
|
|||
|
||||
# Automatic background verification **(PREMIUM ONLY)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Automatic background verification of repositories and wikis was added in
|
||||
GitLab EE 10.6 but is enabled by default only on GitLab EE 11.1. You can
|
||||
disable or enable this feature manually by following
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ restore your original configuration. This process consists of two steps:
|
|||
1. Making the old **primary** node a **secondary** node.
|
||||
1. Promoting a **secondary** node to a **primary** node.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If you have any doubts about the consistency of the data on this node, we recommend setting it up from scratch.
|
||||
|
||||
## Configure the former **primary** node to be a **secondary** node
|
||||
|
|
@ -32,14 +32,14 @@ To bring the former **primary** node up to date:
|
|||
sudo gitlab-ctl start
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you [disabled the **primary** node permanently](index.md#step-2-permanently-disable-the-primary-node),
|
||||
you need to undo those steps now. For Debian/Ubuntu you just need to run
|
||||
`sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
|
||||
the GitLab instance from scratch and set it up as a **secondary** node by
|
||||
following [Setup instructions](../setup/index.md). In this case, you don't need to follow the next step.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
|
||||
for this node during disaster recovery procedure you may need to [block
|
||||
all the writes to this node](planned_failover.md#prevent-updates-to-the-primary-node)
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ failover with minimal effort, in a disaster situation.
|
|||
|
||||
See [Geo limitations](../index.md#limitations) for more information.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Disaster recovery for multi-secondary configurations is in **Alpha**.
|
||||
For the latest updates, check the [Disaster Recovery epic for complete maturity](https://gitlab.com/groups/gitlab-org/-/epics/590).
|
||||
Multi-secondary configurations require the complete re-synchronization and re-configuration of all non-promoted secondaries and
|
||||
|
|
@ -36,7 +36,7 @@ order to avoid unnecessary data loss.
|
|||
|
||||
### Step 2. Permanently disable the **primary** node
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
If the **primary** node goes offline, there may be data saved on the **primary** node
|
||||
that has not been replicated to the **secondary** node. This data should be treated
|
||||
as lost if you proceed.
|
||||
|
|
@ -58,7 +58,7 @@ must disable the **primary** node.
|
|||
sudo systemctl disable gitlab-runsvdir
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
|
||||
started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
|
||||
It may be safest to uninstall the GitLab package completely:
|
||||
|
|
@ -67,7 +67,7 @@ must disable the **primary** node.
|
|||
yum remove gitlab-ee
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
|
||||
or any other distribution based on the Upstart init system, you can prevent GitLab
|
||||
from starting if the machine reboots by doing the following:
|
||||
|
|
@ -140,7 +140,7 @@ Note the following when promoting a secondary:
|
|||
secondary. If the node is paused, be sure to resume before promoting. This
|
||||
issue has been fixed in GitLab 13.4 and later.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
|
||||
a point-in-time recovery to the last known state.
|
||||
Data that was created on the primary while the secondary was paused will be lost.
|
||||
|
|
@ -180,7 +180,7 @@ secondary is paused fails. Do not pause replication before promoting a
|
|||
secondary. If the node is paused, be sure to resume before promoting. This
|
||||
issue has been fixed in GitLab 13.4 and later.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
|
||||
a point-in-time recovery to the last known state.
|
||||
Data that was created on the primary while the secondary was paused will be lost.
|
||||
|
|
@ -301,7 +301,7 @@ secondary domain, like changing Git remotes and API URLs.
|
|||
external_url 'https://<new_external_url>'
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Changing `external_url` won't prevent access via the old secondary URL, as
|
||||
long as the secondary DNS records are still intact.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
type: howto
|
||||
---
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
This runbook is in **alpha**. For complete, production-ready documentation, see the
|
||||
[disaster recovery documentation](../index.md).
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ What is not covered:
|
|||
|
||||
### Preparation
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Before following any of those steps, make sure you have `root` access to the
|
||||
**secondary** to promote it, since there isn't provided an automated way to
|
||||
promote a Geo replica and perform a failover.
|
||||
|
|
@ -134,7 +134,7 @@ follow these steps to avoid unnecessary data loss:
|
|||
|
||||
1. Finish replicating and verifying all data:
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Not all data is automatically replicated. Read more about
|
||||
[what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ follow these steps to avoid unnecessary data loss:
|
|||
|
||||
1. In this final step, you need to permanently disable the **primary** node.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
When the **primary** node goes offline, there may be data saved on the **primary** node
|
||||
that has not been replicated to the **secondary** node. This data should be treated
|
||||
as lost if you proceed.
|
||||
|
|
@ -188,12 +188,12 @@ follow these steps to avoid unnecessary data loss:
|
|||
sudo systemctl disable gitlab-runsvdir
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
|
||||
started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
|
||||
It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
|
||||
or any other distribution based on the Upstart init system, you can prevent GitLab
|
||||
from starting if the machine reboots as `root` with
|
||||
|
|
@ -213,12 +213,12 @@ follow these steps to avoid unnecessary data loss:
|
|||
|
||||
### Promoting the **secondary** node
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
A new **secondary** should not be added at this time. If you want to add a new
|
||||
**secondary**, do this after you have completed the entire process of promoting
|
||||
the **secondary** to the **primary**.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If you encounter an `ActiveRecord::RecordInvalid: Validation failed: Name has already been taken` error during this process, read
|
||||
[the troubleshooting advice](../../replication/troubleshooting.md#fixing-errors-during-a-failover-or-when-promoting-a-secondary-to-a-primary-node).
|
||||
|
||||
|
|
@ -233,7 +233,7 @@ secondary is paused fails. Do not pause replication before promoting a
|
|||
secondary. If the node is paused, be sure to resume before promoting. This
|
||||
issue has been fixed in GitLab 13.4 and later.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If the secondary node [has been paused](../../../geo/index.md#pausing-and-resuming-replication), this performs
|
||||
a point-in-time recovery to the last known state.
|
||||
Data that was created on the primary while the secondary was paused will be lost.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
type: howto
|
||||
---
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
This runbook is in **alpha**. For complete, production-ready documentation, see the
|
||||
[disaster recovery documentation](../index.md).
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ What is not covered:
|
|||
|
||||
### Preparation
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Before following any of those steps, make sure you have `root` access to the
|
||||
**secondary** to promote it, since there isn't provided an automated way to
|
||||
promote a Geo replica and perform a failover.
|
||||
|
|
@ -122,7 +122,7 @@ follow these steps to avoid unnecessary data loss:
|
|||
|
||||
1. Finish replicating and verifying all data:
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Not all data is automatically replicated. Read more about
|
||||
[what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ follow these steps to avoid unnecessary data loss:
|
|||
|
||||
1. In this final step, you need to permanently disable the **primary** node.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
When the **primary** node goes offline, there may be data saved on the **primary** node
|
||||
that has not been replicated to the **secondary** node. This data should be treated
|
||||
as lost if you proceed.
|
||||
|
|
@ -176,12 +176,12 @@ follow these steps to avoid unnecessary data loss:
|
|||
sudo systemctl disable gitlab-runsvdir
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
|
||||
started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
|
||||
It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
(**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
|
||||
or any other distribution based on the Upstart init system, you can prevent GitLab
|
||||
from starting if the machine reboots as `root` with
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Geo is the solution for widely distributed development teams and for providing a
|
|||
|
||||
## Overview
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Geo undergoes significant changes from release to release. Upgrades **are** supported and [documented](#updating-geo), but you should ensure that you're using the right version of the documentation for your installation.
|
||||
|
||||
Fetching large repositories can take a long time for teams located far from a single GitLab instance.
|
||||
|
|
@ -143,11 +143,11 @@ The following table lists basic ports that must be open between the **primary**
|
|||
|
||||
See the full list of ports used by GitLab in [Package defaults](https://docs.gitlab.com/omnibus/package-information/defaults.html)
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Web terminal](../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
|
||||
When using HTTP or HTTPS proxying, your load balancer must be configured to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the [web terminal](../integration/terminal.md) integration guide for more details.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
When using HTTPS protocol for port 443, you will need to add an SSL certificate to the load balancers.
|
||||
If you wish to terminate SSL at the GitLab application server instead, use TCP protocol.
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ If you wish to terminate SSL at the GitLab application server instead, use TCP p
|
|||
|
||||
We recommend that if you use LDAP on your **primary** node, you also set up secondary LDAP servers on each **secondary** node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the **secondary** node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
It is possible for all **secondary** nodes to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server will be available in a [disaster recovery](disaster_recovery/index.md) scenario if a **secondary** node is promoted to be a **primary** node.
|
||||
|
||||
Check for instructions on how to set up replication in your LDAP service. Instructions will be different depending on the software or service used. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).
|
||||
|
|
@ -207,7 +207,7 @@ secondary is paused fails. Do not pause replication before promoting a
|
|||
secondary. If the node is paused, be sure to resume before promoting. This
|
||||
issue has been fixed in GitLab 13.4 and later.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Pausing and resuming of replication is currently only supported for Geo installations using an
|
||||
Omnibus GitLab-managed database. External databases are currently not supported.
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ To find out how to disable Geo, see [Disabling Geo](replication/disable_geo.md).
|
|||
|
||||
## Limitations
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
This list of limitations only reflects the latest version of GitLab. If you are using an older version, extra limitations may be in place.
|
||||
|
||||
- Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/-/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: howto
|
|||
|
||||
## Configuring a new **secondary** node
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This is the final step in setting up a **secondary** Geo node. Stages of the
|
||||
setup process must be completed in the documented order.
|
||||
Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
|
||||
|
|
@ -23,7 +23,7 @@ The basic steps of configuring a **secondary** node are to:
|
|||
You are encouraged to first read through all the steps before executing them
|
||||
in your testing/production environment.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
**Do not** set up any custom authentication for the **secondary** nodes. This will be handled by the **primary** node.
|
||||
Any change that requires access to the **Admin Area** needs to be done in the
|
||||
**primary** node because the **secondary** node is a read-only replica.
|
||||
|
|
@ -157,7 +157,7 @@ keys must be manually replicated to the **secondary** node.
|
|||
for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The output for private keys and public keys command should generate the same fingerprint.
|
||||
|
||||
1. Restart `sshd` on your **secondary** node:
|
||||
|
|
|
|||
|
|
@ -64,17 +64,17 @@ We need to make Docker Registry send notification events to the
|
|||
]
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
|
||||
that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you use an external Registry (not the one integrated with GitLab), you must add
|
||||
these settings to its configuration yourself. In this case, you will also have to specify
|
||||
notification secret in `registry.notification_secret` section of
|
||||
`/etc/gitlab/gitlab.rb` file.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you use GitLab HA, you will also have to specify
|
||||
the notification secret in `registry.notification_secret` section of
|
||||
`/etc/gitlab/gitlab.rb` file for every web node.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Though these instructions use [AWS Route53](https://aws.amazon.com/route53/),
|
|||
other services such as [Cloudflare](https://www.cloudflare.com/) could be used
|
||||
as well.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You can also use a load balancer to distribute web UI or API traffic to
|
||||
[multiple Geo **secondary** nodes](../../../user/admin_area/geo_nodes.md#multiple-secondary-nodes-behind-a-load-balancer).
|
||||
Importantly, the **primary** node cannot yet be included. See the feature request
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ network topology of your deployment.
|
|||
The only external way to access the two Geo deployments is by HTTPS at
|
||||
`gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The **primary** and **secondary** Geo deployments must be able to communicate to each other over HTTPS.
|
||||
|
||||
## Redis and PostgreSQL for multiple nodes
|
||||
|
|
@ -37,7 +37,7 @@ Geo supports:
|
|||
- Redis and PostgreSQL on the **primary** node configured for multiple nodes.
|
||||
- Redis on **secondary** nodes configured for multiple nodes.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Support for PostgreSQL on **secondary** nodes in multi-node configuration
|
||||
[is planned](https://gitlab.com/groups/gitlab-org/-/epics/2536).
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ For more information about setting up a multi-node PostgreSQL cluster and Redis
|
|||
[PostgreSQL](../../postgresql/replication_and_failover.md) and
|
||||
[Redis](../../redis/replication_and_failover.md), respectively.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document.
|
||||
|
||||
## Prerequisites: Two working GitLab multi-node clusters
|
||||
|
|
@ -90,7 +90,7 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
|
|||
|
||||
After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
PostgreSQL and Redis should have already been disabled on the
|
||||
application servers, and connections from the application servers to those
|
||||
services on the backend servers configured, during normal GitLab multi-node set up. See
|
||||
|
|
@ -136,13 +136,13 @@ documentation:
|
|||
- [Gitaly](../../gitaly/index.md), which will store data that is
|
||||
synchronized from the **primary** node.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[NFS](../../nfs.md) can be used in place of Gitaly but is not
|
||||
recommended.
|
||||
|
||||
### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The following documentation assumes the database will be run on
|
||||
a single node only. Multi-node PostgreSQL on **secondary** nodes is
|
||||
[not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
|
||||
|
|
@ -232,7 +232,7 @@ If using an external PostgreSQL instance, refer also to
|
|||
|
||||
### Step 3: Configure the tracking database on the **secondary** node
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This documentation assumes the tracking database will be run on
|
||||
only a single machine, rather than as a PostgreSQL cluster.
|
||||
|
||||
|
|
@ -365,14 +365,14 @@ then make the following modifications:
|
|||
registry['gid'] = 9002
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you had set up PostgreSQL cluster using the omnibus package and you had set
|
||||
up `postgresql['sql_user_password'] = 'md5 digest of secret'` setting, keep in
|
||||
mind that `gitlab_rails['db_password']` and `geo_secondary['db_password']`
|
||||
mentioned above contains the plaintext passwords. This is used to let the Rails
|
||||
servers connect to the databases.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Make sure that current node IP is listed in `postgresql['md5_auth_cidr_addresses']` setting of your remote database.
|
||||
|
||||
After making these changes [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ To have:
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10586) in GitLab 12.4.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale. The main limitations are a lack of testing at scale and no verification of any replicated data.
|
||||
|
||||
**Secondary** nodes can replicate files stored on the **primary** node regardless of
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl
|
|||
sudo gitlab-psql
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
|
||||
|
||||
1. Find the name of the relevant replication slot. This is the slot that is specified with `--slot-name` when running the replicate command: `gitlab-ctl replicate-geo-database`.
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
|
|||
sudo gitlab-psql
|
||||
```
|
||||
|
||||
Note: **Note:** Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
|
||||
Note: Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
|
||||
|
||||
1. View your replication slots with:
|
||||
|
||||
|
|
@ -467,7 +467,7 @@ to start again from scratch, there are a few steps that can help you:
|
|||
|
||||
1. _(Optional)_ Rename other data folders and create new ones
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
You may still have files on the **secondary** node that have been removed from **primary** node but
|
||||
removal have not been reflected. If you skip this step, they will never be removed
|
||||
from this Geo node.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ type: howto
|
|||
|
||||
# Updating the Geo nodes **(PREMIUM ONLY)**
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Read these sections carefully before updating your Geo nodes. Not following
|
||||
version-specific update steps may result in unexpected downtime. If you have
|
||||
any specific questions, [contact Support](https://about.gitlab.com/support/#contact-support).
|
||||
|
|
@ -20,7 +20,7 @@ Updating Geo nodes involves performing:
|
|||
|
||||
## General update steps
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
These general update steps are not intended for [high-availability deployments](https://docs.gitlab.com/omnibus/update/README.html#multi-node--ha-deployment), and will cause downtime. If you want to avoid downtime, consider using [zero downtime updates](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
|
||||
|
||||
To update the Geo nodes when a new GitLab version is released, update **primary**
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ the recommended procedure, see the
|
|||
|
||||
## Updating to GitLab 12.9
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
GitLab 12.9.0 through GitLab 12.9.3 are affected by [a bug that stops
|
||||
repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
|
||||
The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
|
||||
|
|
@ -203,14 +203,14 @@ For the recommended procedure, see the
|
|||
|
||||
## Updating to GitLab 12.0
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
This version is affected by a [bug that results in new LFS objects not being
|
||||
replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
|
||||
The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
|
||||
|
||||
## Updating to GitLab 11.11
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
This version is affected by a [bug that results in new LFS objects not being
|
||||
replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
|
||||
The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
|
||||
|
|
@ -376,7 +376,7 @@ the now-unused SSH keys from your secondaries, as they may cause problems if the
|
|||
|
||||
### Hashed Storage
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Hashed storage is in **Alpha**. It is considered experimental and not
|
||||
production-ready. See [Hashed Storage](../../repository_storage_types.md) for more detail.
|
||||
|
||||
|
|
@ -387,7 +387,7 @@ migrated we recommend leaving Hashed Storage enabled.
|
|||
|
||||
## Updating to GitLab 10.1
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Hashed storage is in **Alpha**. It is considered experimental and not
|
||||
production-ready. See [Hashed Storage](../../repository_storage_types.md) for more detail.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ type: howto
|
|||
|
||||
# Geo database replication **(PREMIUM ONLY)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If your GitLab installation uses external (not managed by Omnibus) PostgreSQL
|
||||
instances, the Omnibus roles will not be able to perform all necessary
|
||||
configuration steps. In this case,
|
||||
[follow the Geo with external PostgreSQL instances document instead](external_database.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The stages of the setup process must be completed in the documented order.
|
||||
Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ The following guide assumes that:
|
|||
you have a new **secondary** server set up with the same versions of the OS,
|
||||
PostgreSQL, and GitLab on all nodes.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Geo works with streaming replication. Logical replication is not supported at this time.
|
||||
There is an [issue where support is being discussed](https://gitlab.com/gitlab-org/gitlab/-/issues/7420).
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. GitLab 10.4 and up only: Do the following to make sure the `gitlab` database user has a password defined:
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Until FDW settings are removed in GitLab version 14.0, avoid using single or double quotes in the
|
||||
password for PostgreSQL as that will lead to errors when reconfiguring.
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
connect to the **primary** node's database. For this reason, we need the address of
|
||||
each node.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For external PostgreSQL instances, see [additional instructions](external_database.md).
|
||||
|
||||
If you are using a cloud provider, you can lookup the addresses for each
|
||||
|
|
@ -171,7 +171,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
corresponding to the given address. See [the PostgreSQL documentation](https://www.postgresql.org/docs/11/runtime-config-connection.html)
|
||||
for more details.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you need to use `0.0.0.0` or `*` as the listen_address, you will also need to add
|
||||
`127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
|
||||
`127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
|
||||
|
|
@ -290,7 +290,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
gitlab-ctl stop sidekiq
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This step is important so we don't try to execute anything before the node is fully configured.
|
||||
|
||||
1. [Check TCP connectivity](../../raketasks/maintenance.md) to the **primary** node's PostgreSQL server:
|
||||
|
|
@ -299,7 +299,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
gitlab-rake gitlab:tcp_check[<primary_node_ip>,5432]
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If this step fails, you may be using the wrong IP address, or a firewall may
|
||||
be preventing access to the server. Check the IP address, paying close
|
||||
attention to the difference between public and private addresses and ensure
|
||||
|
|
@ -404,7 +404,7 @@ needed files for streaming replication.
|
|||
The directories used are the defaults that are set up in Omnibus. If you have
|
||||
changed any defaults, configure it as you see fit replacing the directories and paths.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Make sure to run this on the **secondary** server as it removes all PostgreSQL's
|
||||
data before running `pg_basebackup`.
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ data before running `pg_basebackup`.
|
|||
|
||||
1. Execute the command below to start a backup/restore and begin the replication
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Each Geo **secondary** node must have its own unique replication slot name.
|
||||
Using the same slot name between two secondaries will break PostgreSQL replication.
|
||||
|
||||
|
|
@ -431,10 +431,10 @@ data before running `pg_basebackup`.
|
|||
--host=<primary_node_ip>
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Replication slot names must only contain lowercase letters, numbers, and the underscore character.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.4, a seed project is added when GitLab is first installed. This makes it necessary to pass `--force` even
|
||||
on a new Geo secondary node. There is an [issue to account for seed projects](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5618)
|
||||
when checking the database.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This document is relevant if you are using a PostgreSQL instance that is *not
|
|||
managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or
|
||||
manually installed and configured PostgreSQL instances.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
We strongly recommend running Omnibus-managed instances as they are actively
|
||||
developed and tested. We aim to be compatible with most external
|
||||
(not managed by Omnibus) databases but we do not guarantee compatibility.
|
||||
|
|
@ -186,7 +186,7 @@ to grant additional roles to your tracking database user (by default, this is
|
|||
If you have an external database ready to be used as the tracking database,
|
||||
follow the instructions below to use it:
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you want to use AWS RDS as a tracking database, make sure it has access to
|
||||
the secondary database. Unfortunately, just assigning the same security group is not enough as
|
||||
outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to explicitly add an inbound
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ These instructions assume you have a working instance of GitLab. They guide you
|
|||
1. Making your existing instance the **primary** node.
|
||||
1. Adding **secondary** nodes.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
The steps below should be followed in the order they appear. **Make sure the GitLab version is the same on all nodes.**
|
||||
|
||||
## Using Omnibus GitLab
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/git_annex.html'
|
|||
|
||||
# Git annex
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
[Git Annex support was removed](https://gitlab.com/gitlab-org/gitlab/-/issues/1648)
|
||||
in GitLab 9.0. Read through the [migration guide from git-annex to Git LFS](../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md).
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ one is located in `config.yml` of GitLab Shell.
|
|||
|
||||
## Using GitLab git-annex
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Your Git remotes must be using the SSH protocol, not HTTP(S).
|
||||
|
||||
Here is an example workflow of uploading a very large file and then checking it
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ In the Gitaly documentation:
|
|||
GitLab end users do not have direct access to Gitaly. Gitaly only manages Git
|
||||
repository access for GitLab. Other types of GitLab data aren't accessed using Gitaly.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
From GitLab 13.0, Gitaly support for NFS is deprecated. As of GitLab 14.0, NFS-related issues
|
||||
with Gitaly will no longer be addressed. Upgrade to [Gitaly Cluster](praefect.md) as soon as
|
||||
possible. Watch for [tools to enable bulk move](https://gitlab.com/groups/gitlab-org/-/epics/4916)
|
||||
|
|
@ -69,7 +69,7 @@ this default configuration used by:
|
|||
However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span
|
||||
multiple machines.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
When configured to run on their own servers, Gitaly servers
|
||||
[must be upgraded](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers) before Gitaly
|
||||
clients in your cluster.
|
||||
|
|
@ -141,7 +141,7 @@ We assume your GitLab installation has three repository storages:
|
|||
|
||||
You can use as few as one server with one repository storage if desired.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is just an arbitrary password selected by
|
||||
the administrator. It is unrelated to tokens created for the GitLab API or other similar web API
|
||||
tokens.
|
||||
|
|
@ -434,7 +434,7 @@ server (with `gitaly_address`) unless you setup with special
|
|||
path: /some/local/path
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`/some/local/path` should be set to a local folder that exists, however no data is stored in
|
||||
this folder. This requirement is scheduled to be removed when
|
||||
[this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
|
||||
|
|
@ -647,7 +647,7 @@ To configure Gitaly with TLS:
|
|||
path: /some/local/path
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`/some/local/path` should be set to a local folder that exists, however no data is stored
|
||||
in this folder. This requirement is scheduled to be removed when
|
||||
[Gitaly issue #1282](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
|
||||
|
|
@ -723,7 +723,7 @@ We recommend:
|
|||
- At least 300MB memory per worker.
|
||||
- No more than one worker per core.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`gitaly-ruby` is planned to be eventually removed. To track progress, see the
|
||||
[Remove the Gitaly-Ruby sidecar](https://gitlab.com/groups/gitlab-org/-/epics/2862) epic.
|
||||
|
||||
|
|
@ -805,7 +805,7 @@ You can observe the behavior of this queue using the Gitaly logs and Prometheus:
|
|||
- `gitaly_rate_limiting_queued`.
|
||||
- `gitaly_rate_limiting_seconds`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Though the name of the Prometheus metric contains `rate_limiting`, it is a concurrency limiter, not
|
||||
a rate limiter. If a Gitaly client makes 1000 requests in a row very quickly, concurrency does not
|
||||
exceed 1 and the concurrency limiter has no effect.
|
||||
|
|
@ -915,7 +915,7 @@ your Gitaly servers as follows:
|
|||
gitaly['auth_transitioning'] = false
|
||||
```
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Without completing this step, you have **no Gitaly authentication**.
|
||||
|
||||
### Verify authentication is enforced
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ be run in a clustered configuration to increase fault tolerance. In this
|
|||
configuration, every Git repository is stored on every Gitaly node in the
|
||||
cluster. Multiple clusters (or shards), can be configured.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Gitaly Clusters can be created using [GitLab Core](https://about.gitlab.com/pricing/#self-managed)
|
||||
and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers
|
||||
only. Not available in GitLab.com.
|
||||
|
|
@ -188,7 +188,7 @@ We note in the instructions below where these secrets are required.
|
|||
|
||||
### PostgreSQL
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Do not store the GitLab application database and the Praefect
|
||||
database on the same PostgreSQL server if using
|
||||
[Geo](../geo/index.md). The replication state is internal to each instance
|
||||
|
|
@ -287,7 +287,7 @@ The `praefect` user and its password should be included in the file (default is
|
|||
`userlist.txt`) used by PgBouncer if the [`auth_file`](https://www.pgbouncer.org/config.html#auth_file)
|
||||
configuration option is set.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
By default PgBouncer uses port `6432` to accept incoming
|
||||
connections. You can change it by setting the [`listen_port`](https://www.pgbouncer.org/config.html#listen_port)
|
||||
configuration option. We recommend setting it to the default port value (`5432`) used by
|
||||
|
|
@ -298,7 +298,7 @@ PostgreSQL instances. Otherwise you should change the configuration parameter
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2634) in GitLab 13.4, Praefect nodes can no longer be designated as `primary`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If there are multiple Praefect nodes, complete these steps for **each** node.
|
||||
|
||||
To complete this section you need a [configured PostgreSQL server](#postgresql), including:
|
||||
|
|
@ -398,7 +398,7 @@ application server, or a Gitaly node.
|
|||
so we use `default` here as well. This cluster has three Gitaly nodes `gitaly-1`,
|
||||
`gitaly-2`, and `gitaly-3`, which are intended to be replicas of each other.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If you have data on an already existing storage called
|
||||
`default`, you should configure the virtual storage with another name and
|
||||
[migrate the data to the Gitaly Cluster storage](#migrate-existing-repositories-to-gitaly-cluster)
|
||||
|
|
@ -573,7 +573,7 @@ To configure Praefect with TLS:
|
|||
path: /some/local/path
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`/some/local/path` should be set to a local folder that exists, however no
|
||||
data is stored in this folder. This requirement is scheduled to be removed when
|
||||
[this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
|
||||
|
|
@ -602,7 +602,7 @@ To configure Praefect with TLS:
|
|||
|
||||
### Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Complete these steps for **each** Gitaly node.
|
||||
|
||||
To complete this section you need:
|
||||
|
|
@ -763,7 +763,7 @@ internal traffic from the GitLab application to the Praefect nodes. The
|
|||
specifics on which load balancer to use or the exact configuration is beyond the
|
||||
scope of the GitLab documentation.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The load balancer must be configured to accept traffic from the Gitaly nodes in
|
||||
addition to the GitLab nodes. Some requests handled by
|
||||
[`gitaly-ruby`](index.md#gitaly-ruby) sidecar processes call into the main Gitaly
|
||||
|
|
@ -817,7 +817,7 @@ Particular attention should be shown to:
|
|||
1. Disable the default Gitaly service running on the GitLab host. It isn't needed
|
||||
because GitLab connects to the configured cluster.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If you have existing data stored on the default Gitaly storage,
|
||||
you should [migrate the data your Gitaly Cluster storage](#migrate-existing-repositories-to-gitaly-cluster)
|
||||
first.
|
||||
|
|
@ -1116,7 +1116,7 @@ available:
|
|||
- In GitLab 13.3 and later, `-partially-replicated` that specifies whether to display a list of
|
||||
[outdated replicas of writable repositories](#outdated-replicas-of-writable-repositories).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`dataloss` is still in beta and the output format is subject to change.
|
||||
|
||||
To check for outdated replicas of read-only repositories, run:
|
||||
|
|
@ -1214,7 +1214,7 @@ Praefect provides the following subcommands to re-enable writes:
|
|||
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage <virtual-storage> -repository <relative-path> -authoritative-storage <storage-name>
|
||||
```
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
`accept-dataloss` causes permanent data loss by overwriting other versions of the repository. Data
|
||||
[recovery efforts](#data-recovery) must be performed before using it.
|
||||
|
||||
|
|
@ -1278,7 +1278,7 @@ Gitaly Cluster automatically.
|
|||
|
||||
Repositories may be moved from one storage location using the [Project repository storage moves API](../../api/project_repository_storage_moves.md):
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The Project repository storage moves API [cannot move all repository types](../../api/project_repository_storage_moves.md#limitations).
|
||||
|
||||
To move repositories to Gitaly Cluster:
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ token = "the secret token"
|
|||
transitioning = true
|
||||
```
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Remember to disable `transitioning` when you are done
|
||||
changing your token settings.
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ To set up a basic Postfix mail server with IMAP access on Ubuntu, follow the
|
|||
|
||||
### Security concerns
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Be careful when choosing the domain used for receiving incoming email.
|
||||
|
||||
For example, suppose your top-level company domain is `hooli.com`.
|
||||
|
|
@ -112,7 +112,7 @@ Alternatively, use a dedicated domain for GitLab email communications such as
|
|||
See GitLab issue [#30366](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30366)
|
||||
for a real-world example of this exploit.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Use a mail server that has been configured to reduce
|
||||
spam.
|
||||
A Postfix mail server that is running on a default configuration, for example,
|
||||
|
|
@ -253,7 +253,7 @@ incoming_email:
|
|||
|
||||
Example configuration for Gmail/G Suite. Assumes mailbox `gitlab-incoming@gmail.com`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`incoming_email_email` cannot be a Gmail alias account.
|
||||
|
||||
Example for Omnibus installs:
|
||||
|
|
@ -442,7 +442,7 @@ Example configurations for Microsoft Office 365 with IMAP enabled.
|
|||
|
||||
##### Sub-addressing mailbox
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
As of September 2020 sub-addressing support
|
||||
[has been added to Office 365](https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/18612754-support-for-dynamic-email-aliases-in-office-36). This feature is not
|
||||
enabled by default, and must be enabled through PowerShell.
|
||||
|
|
@ -451,7 +451,7 @@ This series of PowerShell commands enables [sub-addressing](#email-sub-addressin
|
|||
at the organization level in Office 365. This allows all mailboxes in the organization
|
||||
to receive sub-addressed mail:
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This series of commands enables sub-addressing at the organization
|
||||
level in Office 365. This allows all mailboxes in the organization
|
||||
to receive sub-addressed mail.
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ information useful for troubleshooting, but if you are experiencing trouble with
|
|||
GitLab instance, you should check your [support options](https://about.gitlab.com/support/)
|
||||
before referring to these documents.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Using the commands listed in the documentation below could result in data loss or
|
||||
other damage to a GitLab instance, and should only be used by experienced administrators
|
||||
who are aware of the risks.
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ that, login with an Admin account and do following:
|
|||
- Check **Enable PlantUML** checkbox.
|
||||
- Set the PlantUML instance as `https://gitlab.example.com/-/plantuml/`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you are using a PlantUML server running v1.2020.9 and
|
||||
above (for example, [plantuml.com](https://plantuml.com)), set the `PLANTUML_ENCODING`
|
||||
environment variable to enable the `deflate` compression. On Omnibus,
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Only project maintainers and owners can access web terminals.
|
||||
|
||||
With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
|
||||
|
|
@ -51,7 +51,7 @@ detail below.
|
|||
|
||||
## Enabling and disabling terminal support
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
AWS Elastic Load Balancers (ELBs) do not support web sockets.
|
||||
AWS Application Load Balancers (ALBs) must be used if you want web terminals
|
||||
to work. See [AWS Elastic Load Balancing Product Comparison](https://aws.amazon.com/elasticloadbalancing/features/#compare)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ type: reference
|
|||
|
||||
# Issue closing pattern **(CORE ONLY)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This is the administration documentation. There is a separate [user documentation](../user/project/issues/managing_issues.md#closing-issues-automatically)
|
||||
on issue closing pattern.
|
||||
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ In a multi-server setup you must use one of the options to
|
|||
|
||||
#### Object Storage Settings
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.2 and later, we recommend using the
|
||||
[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
|
||||
This section describes the earlier configuration format.
|
||||
|
|
@ -190,7 +190,7 @@ _The artifacts are stored by default in
|
|||
In some cases, you may need to run the [orphan artifact file cleanup Rake task](../raketasks/cleanup.md#remove-orphan-artifact-files)
|
||||
to clean up orphaned artifacts.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
JUnit test report artifact (`junit.xml.gz`) migration
|
||||
[was not supported until GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/27698#note_317190991)
|
||||
by the `gitlab:artifacts:migrate` script.
|
||||
|
|
@ -243,7 +243,7 @@ _The artifacts are stored by default in
|
|||
In some cases, you may need to run the [orphan artifact file cleanup Rake task](../raketasks/cleanup.md#remove-orphan-artifact-files)
|
||||
to clean up orphaned artifacts.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
JUnit test report artifact (`junit.xml.gz`) migration
|
||||
[was not supported until GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/27698#note_317190991)
|
||||
by the `gitlab:artifacts:migrate` script.
|
||||
|
|
@ -481,7 +481,7 @@ the number you want.
|
|||
|
||||
#### Delete job artifacts from jobs completed before a specific date
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
These commands remove data permanently from the database and from disk. We
|
||||
highly recommend running them only under the guidance of a Support Engineer, or
|
||||
running them in a test environment with a backup of the instance ready to be
|
||||
|
|
@ -507,7 +507,7 @@ If you need to manually remove job artifacts associated with multiple jobs while
|
|||
|
||||
1. Delete job artifacts older than a specific date:
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This step also erases artifacts that users have chosen to
|
||||
["keep"](../ci/pipelines/job_artifacts.md#browsing-artifacts).
|
||||
|
||||
|
|
@ -528,7 +528,7 @@ If you need to manually remove job artifacts associated with multiple jobs while
|
|||
|
||||
#### Delete job artifacts and logs from jobs completed before a specific date
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
These commands remove data permanently from the database and from disk. We
|
||||
highly recommend running them only under the guidance of a Support Engineer, or
|
||||
running them in a test environment with a backup of the instance ready to be
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -d
|
|||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18169) in GitLab 10.4.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This beta feature is off by default. See below for how to [enable or disable](#enabling-incremental-logging) it.
|
||||
|
||||
By combining the process with object storage settings, we can completely bypass
|
||||
|
|
@ -184,8 +184,8 @@ Feature.enabled?(:ci_enable_live_trace)
|
|||
Feature.enable(:ci_enable_live_trace)
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
The transition period is handled gracefully. Upcoming logs are
|
||||
NOTE:
|
||||
The transition period is handled gracefully. Upcoming logs are
|
||||
generated with the incremental architecture, and on-going logs stay with the
|
||||
legacy architecture, which means that on-going logs aren't forcibly
|
||||
re-generated with the incremental architecture.
|
||||
|
|
@ -196,7 +196,7 @@ re-generated with the incremental architecture.
|
|||
Feature.disable('ci_enable_live_trace')
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The transition period is handled gracefully. Upcoming logs are generated
|
||||
with the legacy architecture, and on-going incremental logs stay with the incremental
|
||||
architecture, which means that on-going incremental logs aren't forcibly re-generated
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ GitLab provides two different options for the uploading mechanism: "Direct uploa
|
|||
|
||||
[Read more about using object storage with GitLab](../object_storage.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.2 and later, we recommend using the
|
||||
[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
|
||||
This section describes the earlier configuration format.
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ The ActionCable connection or channel class is used as the `controller`.
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Starting with GitLab 12.5, if an error occurs, an
|
||||
`exception` field is included with `class`, `message`, and
|
||||
`backtrace`. Previous versions included an `error` field instead of
|
||||
|
|
@ -383,7 +383,7 @@ only. For example:
|
|||
|
||||
## `audit_json.log`
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Most log entries only exist in [GitLab Starter](https://about.gitlab.com/pricing/), however a few exist in GitLab Core.
|
||||
|
||||
This file lives in `/var/log/gitlab/gitlab-rails/audit_json.log` for
|
||||
|
|
@ -1004,7 +1004,7 @@ When [troubleshooting](troubleshooting/index.md) issues that aren't localized to
|
|||
previously listed components, it's helpful to simultaneously gather multiple logs and statistics
|
||||
from a GitLab instance.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
GitLab Support will often ask for one of these, and maintains the required tools.
|
||||
|
||||
### Briefly tail the main logs
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ that only [stores outdated diffs](#alternative-in-database-storage) outside of d
|
|||
|
||||
## Using object storage
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Currently migrating to object storage is **non-reversible**
|
||||
|
||||
Instead of storing the external diffs on disk, we recommended the use of an object
|
||||
|
|
@ -102,7 +102,7 @@ be configured already.
|
|||
|
||||
### Object Storage Settings
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.2 and later, we recommend using the
|
||||
[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
|
||||
This section describes the earlier configuration format.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics
|
|||
|
||||
## Deleting the self monitoring project
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Deleting the self monitoring project removes any changes made to the project. If
|
||||
you create the project again, it's created in its default state.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
> Introduced in GitLab 9.4.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
We intend to [rename IP whitelist as `IP allowlist`](https://gitlab.com/gitlab-org/gitlab/-/issues/7554).
|
||||
|
||||
GitLab provides some [monitoring endpoints](../../user/admin_area/monitoring/health_check.md)
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ To disable Prometheus and all of its exporters, as well as any added in the futu
|
|||
|
||||
### Changing the port and address Prometheus listens on
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
The following change was added in [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/1261). Although possible,
|
||||
it's not recommended to change the port Prometheus listens
|
||||
on, as this might affect or conflict with other services running on the GitLab
|
||||
|
|
@ -183,7 +183,7 @@ ensure that `prometheus['scrape_configs']` is not set in `/etc/gitlab/gitlab.rb`
|
|||
|
||||
### Using an external Prometheus server
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Prometheus and most exporters don't support authentication. We don't recommend exposing them outside the local network.
|
||||
|
||||
A few configuration changes are required to allow GitLab to be monitored by an external Prometheus server. External servers are recommended for [GitLab deployments with multiple nodes](../../reference_architectures/index.md).
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Pages](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196).
|
|||
For data objects such as LFS, Uploads, Artifacts, etc., an [Object Storage service](object_storage.md)
|
||||
is recommended over NFS where possible, due to better performance.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
|
||||
support for NFS for Git repositories is scheduled to be removed. Upgrade to
|
||||
[Gitaly Cluster](gitaly/praefect.md) as soon as possible.
|
||||
|
|
@ -118,7 +118,7 @@ To disable NFS server delegation, do the following:
|
|||
|
||||
1. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The kernel bug may be fixed in
|
||||
[more recent kernels with this commit](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
|
||||
Red Hat Enterprise 7 [shipped a kernel update](https://access.redhat.com/errata/RHSA-2019:2029)
|
||||
|
|
@ -133,7 +133,7 @@ NFS performance with GitLab can in some cases be improved with
|
|||
[direct Git access](gitaly/index.md#direct-access-to-git-in-gitlab) using
|
||||
[Rugged](https://github.com/libgit2/rugged).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
From GitLab 12.1, it will automatically be detected if Rugged can and should be used per storage.
|
||||
|
||||
If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using:
|
||||
|
|
@ -146,7 +146,7 @@ If the Rugged feature flag is explicitly set to either `true` or `false`, GitLab
|
|||
|
||||
#### Improving NFS performance with Puma
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
From GitLab 12.7, Rugged is not automatically enabled if Puma thread count is greater than `1`.
|
||||
|
||||
If you want to use Rugged with Puma, [set Puma thread count to `1`](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings).
|
||||
|
|
@ -344,7 +344,7 @@ sudo ufw allow from <client_ip_address> to any port nfs
|
|||
|
||||
### Upgrade to Gitaly Cluster or disable caching if experiencing data loss
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
|
||||
support for NFS for Git repositories is scheduled to be removed. Upgrade to
|
||||
[Gitaly Cluster](gitaly/praefect.md) as soon as possible.
|
||||
|
|
@ -358,7 +358,7 @@ For example, we have seen [inconsistent updates after a push](https://gitlab.com
|
|||
| `actimeo=0` | Sets the time to zero that the NFS client caches files and directories before requesting fresh information from a server. |
|
||||
| `noac` | Tells the NFS client not to cache file attributes and forces application writes to become synchronous so that local changes to a file become visible on the server immediately. |
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
The `actimeo=0` and `noac` options both result in a significant reduction in performance, possibly leading to timeouts.
|
||||
You may be able to avoid timeouts and data loss using `actimeo=0` and `lookupcache=positive` _without_ `noac`, however
|
||||
we expect the performance reduction will still be significant. As noted above, we strongly recommend upgrading to
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ prefixed with `session:gitlab:`, so they would look like
|
|||
`session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
|
||||
remove the keys in the old format.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The instructions below must be modified in accordance with your
|
||||
configuration settings if you have used the advanced Redis
|
||||
settings outlined in
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ These processes can be used to consume a dedicated set
|
|||
of queues. This can be used to ensure certain queues always have dedicated
|
||||
workers, no matter the number of jobs that need to be processed.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The information in this page applies only to Omnibus GitLab.
|
||||
|
||||
## Available Sidekiq queues
|
||||
|
|
@ -209,7 +209,7 @@ sidekiq['queue_groups'] = [
|
|||
|
||||
### Disable Sidekiq cluster
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Sidekiq cluster is [scheduled](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/240)
|
||||
to be the only way to start Sidekiq in GitLab 14.0.
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ being equal to `max_concurrency`.
|
|||
|
||||
Running a single Sidekiq process is the default in GitLab 12.10 and earlier.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Running Sidekiq directly is scheduled to be removed in GitLab
|
||||
[14.0](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/240).
|
||||
|
||||
|
|
@ -376,7 +376,7 @@ This tells the additional processes how often to check for enqueued jobs.
|
|||
|
||||
## Troubleshoot using the CLI
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
It's recommended to use `/etc/gitlab/gitlab.rb` to configure the Sidekiq processes.
|
||||
If you experience a problem, you should contact GitLab support. Use the command
|
||||
line at your own risk.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
|
||||
> - [Available in](https://gitlab.com/gitlab-org/gitlab/-/issues/3953) GitLab Community Edition 10.4.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This document describes a drop-in replacement for the
|
||||
`authorized_keys` file. For normal (non-deploy key) users, consider using
|
||||
[SSH certificates](ssh_certificates.md). They are even faster, but are not a
|
||||
|
|
@ -80,18 +80,18 @@ Confirm that SSH is working by commenting out your user's key in the `authorized
|
|||
A successful pull would mean that GitLab was able to find the key in the database,
|
||||
since it is not present in the file anymore.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For Omnibus Docker, `AuthorizedKeysCommand` is setup by default in
|
||||
GitLab 11.11 and later.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For Installations from source, the command would be located at
|
||||
`/home/git/gitlab-shell/bin/gitlab-shell-authorized-keys-check` if [the install from source](../../install/installation.md#install-gitlab-shell) instructions were followed.
|
||||
You might want to consider creating a wrapper script somewhere else since this command needs to be
|
||||
owned by `root` and not be writable by group or others. You could also consider changing the ownership of this command
|
||||
as required, but that might require temporary ownership changes during `gitlab-shell` upgrades.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Do not disable writes until SSH is confirmed to be working
|
||||
perfectly, because the file will quickly become out-of-date.
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ operations per second.
|
|||
|
||||
### Simple benchmarking
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This test is naive but may be useful if `fio` is not
|
||||
available on the system. It's possible to receive good results on this
|
||||
test but still have poor performance due to read speed and various other
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
The [Rails console](https://guides.rubyonrails.org/command_line.html#rails-console).
|
||||
provides a way to interact with your GitLab instance from the command line.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
The Rails console interacts directly with GitLab. In many cases,
|
||||
there are no handrails to prevent you from permanently modifying, corrupting
|
||||
or destroying production data. If you would like to explore the Rails console
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Understanding Unicorn and unicorn-worker-killer
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Starting with GitLab 13.0, Puma is the default web server used in GitLab
|
||||
all-in-one package based installations as well as GitLab Helm chart deployments.
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ auth:
|
|||
rootcertbundle: /root/certs/certbundle
|
||||
```
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
If `auth` is not set up, users can pull Docker images without authentication.
|
||||
|
||||
## Container Registry domain configuration
|
||||
|
|
@ -374,7 +374,7 @@ driver for the Container Registry.
|
|||
|
||||
[Read more about using object storage with GitLab](../object_storage.md).
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
GitLab does not back up Docker images that are not stored on the
|
||||
file system. Enable backups with your object storage provider if
|
||||
desired.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ dependency proxies, see the [user guide](../../user/packages/dependency_proxy/in
|
|||
|
||||
## Enabling the Dependency Proxy feature
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Dependency proxy requires the Puma web server to be enabled.
|
||||
|
||||
To enable the dependency proxy feature:
|
||||
|
|
@ -88,7 +88,7 @@ store the blobs of the dependency proxy.
|
|||
|
||||
[Read more about using object storage with GitLab](../object_storage.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.2 and later, we recommend using the
|
||||
[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
|
||||
This section describes the earlier configuration format.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ guides you through the process.
|
|||
|
||||
## Enabling the Packages feature
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
After the Packages feature is enabled, the repositories are available
|
||||
for all new projects by default. To enable it for existing projects, users
|
||||
explicitly do so in the project's settings.
|
||||
|
|
@ -136,7 +136,7 @@ store packages.
|
|||
|
||||
[Read more about using object storage with GitLab](../object_storage.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
We recommend using the [consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration). The following instructions apply to the original config format.
|
||||
|
||||
**Omnibus GitLab installations**
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
|
|
@ -16,7 +16,7 @@ description: 'Learn how to administer GitLab Pages.'
|
|||
GitLab Pages allows for hosting of static sites. It must be configured by an
|
||||
administrator. Separate [user documentation](../../user/project/pages/index.md) is available.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This guide is for Omnibus GitLab installations. If you have installed
|
||||
GitLab from source, see
|
||||
[GitLab Pages administration for source installations](source.md).
|
||||
|
|
@ -68,7 +68,7 @@ Before proceeding with the Pages configuration, you will need to:
|
|||
so that your users don't have to bring their own.
|
||||
1. (Only for custom domains) Have a **secondary IP**.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If your GitLab instance and the Pages daemon are deployed in a private network or behind a firewall, your GitLab Pages websites will only be accessible to devices/users that have access to the private network.
|
||||
|
||||
### Add the domain to the Public Suffix List
|
||||
|
|
@ -101,7 +101,7 @@ where `example.io` is the domain under which GitLab Pages will be served
|
|||
and `192.0.2.1` is the IPv4 address of your GitLab instance and `2001::1` is the
|
||||
IPv6 address. If you don't have IPv6, you can omit the AAAA record.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You should not use the GitLab domain to serve user pages. For more information see the [security section](#security).
|
||||
|
||||
## Configuration
|
||||
|
|
@ -181,7 +181,7 @@ behavior:
|
|||
|
||||
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`inplace_chroot` option might not work with the other features, such as [Pages Access Control](#access-control).
|
||||
The [GitLab Pages README](https://gitlab.com/gitlab-org/gitlab-pages#caveats) has more information about caveats and workarounds.
|
||||
|
||||
|
|
@ -395,7 +395,7 @@ To do that:
|
|||
1. Check the **Disable public access to Pages sites** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
For self-managed installations, all public websites remain private until they are
|
||||
redeployed. This issue will be resolved by
|
||||
[sourcing domain configuration from the GitLab API](https://gitlab.com/gitlab-org/gitlab/-/issues/218357).
|
||||
|
|
@ -427,6 +427,42 @@ Authority (CA) in the system certificate store.
|
|||
|
||||
For Omnibus, this is fixed by [installing a custom CA in Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
### Zip serving and cache configuration
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/392) in GitLab 13.7.
|
||||
|
||||
DANGER: **Warning:**
|
||||
These are advanced settings. The recommended default values are set inside GitLab Pages. You should
|
||||
change these settings only if absolutely necessary. Use extreme caution.
|
||||
|
||||
GitLab Pages can serve content from zip archives through object storage (an
|
||||
[issue](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/485) exists for supporting disk storage
|
||||
as well). It uses an in-memory cache to increase the performance when serving content from a zip
|
||||
archive. You can modify the cache behavior by changing the following configuration flags.
|
||||
|
||||
| Setting | Description |
|
||||
| ------- | ----------- |
|
||||
| `zip_cache_expiration` | The cache expiration interval of zip archives. Must be greater than zero to avoid serving stale content. Default is 60s. |
|
||||
| `zip_cache_cleanup` | The interval at which archives are cleaned from memory if they have already expired. Default is 30s. |
|
||||
| `zip_cache_refresh` | The time interval in which an archive is extended in memory if accessed before `zip_cache_expiration`. This works together with `zip_cache_expiration` to determine if an archive is extended in memory. See the [example below](#zip-cache-refresh-example) for important details. Default is 30s. |
|
||||
| `zip_open_timeout` | The maximum time allowed to open a zip archive. Increase this time for big archives or slow network connections, as doing so may affect the latency of serving Pages. Default is 30s. |
|
||||
|
||||
#### Zip cache refresh example
|
||||
|
||||
Archives are refreshed in the cache (extending the time they are held in memory) if they're accessed
|
||||
before `zip_cache_expiration`, and the time left before expiring is less than or equal to
|
||||
`zip_cache_refresh`. For example, if `archive.zip` is accessed at time 0s, it expires in 60s (the
|
||||
default for `zip_cache_expiration`). In the example below, if the archive is opened again after 15s
|
||||
it is **not** refreshed because the time left for expiry (45s) is greater than `zip_cache_refresh`
|
||||
(default 30s). However, if the archive is accessed again after 45s (from the first time it was
|
||||
opened) it's refreshed. This extends the time the archive remains in memory from
|
||||
`45s + zip_cache_expiration (60s)`, for a total of 105s.
|
||||
|
||||
After an archive reaches `zip_cache_expiration`, it's marked as expired and removed on the next
|
||||
`zip_cache_cleanup` interval.
|
||||
|
||||
|
||||
|
||||
## Activate verbose logging for daemon
|
||||
|
||||
Verbose logging was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2533) in
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# GitLab Pages administration for source installations
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Before attempting to enable GitLab Pages, first make sure you have
|
||||
[installed GitLab](../../install/installation.md) successfully.
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ host that GitLab runs. For example, an entry would look like this:
|
|||
where `example.io` is the domain under which GitLab Pages will be served
|
||||
and `192.0.2.1` is the IP address of your GitLab instance.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You should not use the GitLab domain to serve user pages. For more information
|
||||
see the [security section](#security).
|
||||
|
||||
|
|
@ -349,7 +349,7 @@ world. Custom domains and TLS are supported.
|
|||
|
||||
## NGINX caveats
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The following information applies only for installations from source.
|
||||
|
||||
Be extra careful when setting up the domain name in the NGINX configuration. You must
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ This content has been moved to a [new location](replication_and_failover.md#conf
|
|||
|
||||
1. Run `gitlab-ctl reconfigure`
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If the database was already running, it will need to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
|
||||
|
||||
1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ You also need to take into consideration the underlying network topology, making
|
|||
sure you have redundant connectivity between all Database and GitLab instances
|
||||
to avoid the network becoming a single point of failure.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
As of GitLab 13.3, PostgreSQL 12 is shipped with Omnibus GitLab. Clustering for PostgreSQL 12 is only supported with
|
||||
Patroni. See the [Patroni](#patroni) section for further details. The support for repmgr will not be extended beyond
|
||||
PostgreSQL 11.
|
||||
|
|
@ -460,7 +460,7 @@ Check the [Troubleshooting section](#troubleshooting) before proceeding.
|
|||
# END user configuration
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`pgbouncer_role` was introduced with GitLab 10.3.
|
||||
|
||||
1. Run `gitlab-ctl reconfigure`
|
||||
|
|
@ -985,7 +985,7 @@ after it has been restored to service.
|
|||
gitlab-ctl restart repmgrd
|
||||
```
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
When the server is brought back online, and before
|
||||
you switch it to a standby node, repmgr will report that there are two masters.
|
||||
If there are any clients that are still attempting to write to the old master,
|
||||
|
|
@ -1148,7 +1148,7 @@ If you're running into an issue with a component not outlined here, be sure to c
|
|||
|
||||
## Patroni
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Starting from GitLab 13.1, Patroni is available for **experimental** use to replace repmgr. Due to its
|
||||
experimental nature, Patroni support is **subject to change without notice.**
|
||||
|
||||
|
|
@ -1326,7 +1326,7 @@ For further details, see [Patroni documentation on this subject](https://patroni
|
|||
|
||||
### Switching from repmgr to Patroni
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
Although switching from repmgr to Patroni is fairly straightforward the other way around is not. Rolling back from
|
||||
Patroni to repmgr can be complicated and may involve deletion of data directory. If you need to do that, please contact
|
||||
GitLab support.
|
||||
|
|
@ -1345,7 +1345,7 @@ You can switch an exiting database cluster to use Patroni instead of repmgr with
|
|||
sudo gitlab-ctl stop postgresql
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Ensure that there is no `walsender` process running on the primary node.
|
||||
`ps aux | grep walsender` must not show any running process.
|
||||
|
||||
|
|
@ -1367,7 +1367,7 @@ As of GitLab 13.3, PostgreSQL 11.7 and 12.3 are both shipped with Omnibus GitLab
|
|||
uses PostgreSQL 11 by default. Therefore `gitlab-ctl pg-upgrade` does not automatically upgrade
|
||||
to PostgreSQL 12. If you want to upgrade to PostgreSQL 12, you must ask for it explicitly.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
The procedure for upgrading PostgreSQL in a Patroni cluster is different than when upgrading using repmgr.
|
||||
The following outlines the key differences and important considerations that need to be accounted for when
|
||||
upgrading PostgreSQL.
|
||||
|
|
@ -1401,7 +1401,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
|
|||
gitlab-ctl patroni members
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
`gitlab-ctl pg-upgrade` tries to detect the role of the node. If for any reason the auto-detection
|
||||
does not work or you believe it did not detect the role correctly, you can use the `--leader` or `--replica`
|
||||
arguments to manually override it.
|
||||
|
|
@ -1446,7 +1446,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
|
|||
sudo gitlab-ctl pg-upgrade -V 12
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Reverting PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the same considerations as
|
||||
`gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas,
|
||||
then reverting the leader, and finally reverting the replicas.
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ together with Omnibus GitLab. This is recommended as part of our
|
|||
gitlab_rails['auto_migrate'] = false
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The role `postgres_role` was introduced with GitLab 10.3
|
||||
|
||||
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ As GitLab's database hosts sensitive information, using it unfiltered for analyt
|
|||
implies high security requirements. To help alleviate this constraint, the Pseudonymizer
|
||||
service is used to export GitLab's data in a pseudonymized way.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
This process is not impervious. If the source data is available, it's possible for
|
||||
a user to correlate data to the pseudonymized version.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ The following task will run a [group sync](../auth/ldap/index.md#group-sync) imm
|
|||
when you'd like to update all configured group memberships against LDAP without
|
||||
waiting for the next scheduled group sync to be run.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you'd like to change the frequency at which a group sync is performed,
|
||||
[adjust the cron schedule](../auth/ldap/index.md#adjusting-ldap-group-sync-schedule)
|
||||
instead.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ The Rake task uses three parameters to find uploads to migrate:
|
|||
| `model_class` | string | Type of the model to migrate from. |
|
||||
| `mount_point` | string/symbol | Name of the model's column the uploader is mounted on. |
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
These parameters are mainly internal to GitLab's structure, you may want to refer to the task list
|
||||
instead below.
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ sudo -u git -H bundle exec rake "gitlab:uploads:migrate[DesignManagement::Design
|
|||
If you need to disable [object storage](../../object_storage.md) for any reason, you must first
|
||||
migrate your data out of object storage and back into your local storage.
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
**Extended downtime is required** so no new files are created in object storage during
|
||||
the migration. A configuration setting is planned to allow migrating
|
||||
from object storage to local files with only a brief moment of downtime for configuration changes.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Place GitLab into a read-only state **(CORE ONLY)**
|
||||
|
||||
CAUTION: **Warning:**
|
||||
WARNING:
|
||||
This document should be used as a temporary solution.
|
||||
There's work in progress to make this
|
||||
[possible with Geo](https://gitlab.com/groups/gitlab-org/-/epics/2149).
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Redis replication and failover with Omnibus GitLab **(PREMIUM ONLY)**
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This is the documentation for the Omnibus GitLab packages. For using your own
|
||||
non-bundled Redis, follow the [relevant documentation](replication_and_failover_external.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In Redis lingo, primary is called master. In this document, primary is used
|
||||
instead of master, except the settings where `master` is required.
|
||||
|
||||
|
|
@ -162,7 +162,7 @@ is not achieved (see the odd number of nodes requirement above). In that case,
|
|||
a new attempt will be made after the amount of time defined in
|
||||
`sentinel['failover_timeout']` (in milliseconds).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
We will see where `sentinel['failover_timeout']` is defined later.
|
||||
|
||||
The `failover_timeout` variable has a lot of different use cases. According to
|
||||
|
|
@ -194,7 +194,7 @@ It is assumed that you have installed GitLab and all its components from scratch
|
|||
If you already have Redis installed and running, read how to
|
||||
[switch from a single-machine installation](#switching-from-an-existing-single-machine-installation).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Redis nodes (both primary and replica) will need the same password defined in
|
||||
`redis['password']`. At any time during a failover the Sentinels can
|
||||
reconfigure a node and change its status from primary to replica and vice versa.
|
||||
|
|
@ -277,7 +277,7 @@ If you fail to replicate first, you may loose data (unprocessed background jobs)
|
|||
|
||||
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You can specify multiple roles like sentinel and Redis as:
|
||||
`roles ['redis_sentinel_role', 'redis_master_role']`.
|
||||
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
|
||||
|
|
@ -327,7 +327,7 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
|
|||
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
|
||||
1. Go through the steps again for all the other replica nodes.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
You can specify multiple roles like sentinel and Redis as:
|
||||
`roles ['redis_sentinel_role', 'redis_master_role']`.
|
||||
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
|
||||
|
|
@ -339,7 +339,7 @@ the same Sentinels.
|
|||
|
||||
### Step 3. Configuring the Redis Sentinel instances
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you are using an external Redis Sentinel instance, be sure
|
||||
to exclude the `requirepass` parameter from the Sentinel
|
||||
configuration. This parameter will cause clients to report `NOAUTH
|
||||
|
|
@ -465,7 +465,7 @@ the correct credentials for the Sentinel nodes.
|
|||
While it doesn't require a list of all Sentinel nodes, in case of a failure,
|
||||
it needs to access at least one of the listed.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The following steps should be performed in the GitLab application server
|
||||
which ideally should not have Redis or Sentinels on it for a HA setup.
|
||||
|
||||
|
|
@ -690,7 +690,7 @@ To make this work with Sentinel:
|
|||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
For each persistence class, GitLab will default to using the
|
||||
configuration specified in `gitlab_rails['redis_sentinels']` unless
|
||||
overridden by the previously described settings.
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ The following IPs will be used as an example:
|
|||
- `10.6.0.12`: Consul 2
|
||||
- `10.6.0.13`: Consul 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The configuration processes for the other servers in your reference architecture will
|
||||
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
|
||||
with the other servers.
|
||||
|
|
@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.72`: Sentinel - Cache 2
|
||||
- `10.6.0.73`: Sentinel - Cache 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.82`: Sentinel - Queues 2
|
||||
- `10.6.0.83`: Sentinel - Queues 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -1456,7 +1456,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ The following IPs will be used as an example:
|
|||
- `10.6.0.12`: Consul 2
|
||||
- `10.6.0.13`: Consul 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The configuration processes for the other servers in your reference architecture will
|
||||
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
|
||||
with the other servers.
|
||||
|
|
@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.72`: Sentinel - Cache 2
|
||||
- `10.6.0.73`: Sentinel - Cache 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.82`: Sentinel - Queues 2
|
||||
- `10.6.0.83`: Sentinel - Queues 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -1456,7 +1456,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -396,7 +396,7 @@ are supported and can be added if needed.
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -431,7 +431,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -525,7 +525,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This page describes GitLab reference architecture for up to 3,000 users. For a
|
|||
full list of reference architectures, see
|
||||
[Available reference architectures](index.md#available-reference-architectures).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This reference architecture is designed to help your organization achieve a
|
||||
highly-available GitLab deployment. If you do not have the expertise or need to
|
||||
maintain a highly-available environment, you can have a simpler and less
|
||||
|
|
@ -500,7 +500,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.12`: Consul/Sentinel 2
|
||||
- `10.6.0.13`: Consul/Sentinel 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1114,7 +1114,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -1148,7 +1148,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -1298,7 +1298,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ The following IPs will be used as an example:
|
|||
- `10.6.0.12`: Consul 2
|
||||
- `10.6.0.13`: Consul 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The configuration processes for the other servers in your reference architecture will
|
||||
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
|
||||
with the other servers.
|
||||
|
|
@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.72`: Sentinel - Cache 2
|
||||
- `10.6.0.73`: Sentinel - Cache 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.82`: Sentinel - Queues 2
|
||||
- `10.6.0.83`: Sentinel - Queues 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -1456,7 +1456,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This page describes GitLab reference architecture for up to 5,000 users. For a
|
|||
full list of reference architectures, see
|
||||
[Available reference architectures](index.md#available-reference-architectures).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This reference architecture is designed to help your organization achieve a
|
||||
highly-available GitLab deployment. If you do not have the expertise or need to
|
||||
maintain a highly-available environment, you can have a simpler and less
|
||||
|
|
@ -501,7 +501,7 @@ servers. The following IPs will be used as an example:
|
|||
- `10.6.0.12`: Consul/Sentinel 2
|
||||
- `10.6.0.13`: Consul/Sentinel 3
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you're using an external Redis Sentinel instance, be sure to exclude the
|
||||
`requirepass` parameter from the Sentinel configuration. This parameter causes
|
||||
clients to report `NOAUTH Authentication required.`.
|
||||
|
|
@ -1114,7 +1114,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
[Gitaly Cluster](../gitaly/praefect.md) support
|
||||
for the Reference Architectures is being
|
||||
worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
|
||||
|
|
@ -1148,7 +1148,7 @@ Be sure to note the following items:
|
|||
to restrict access to the Gitaly server. Another option is to
|
||||
[use TLS](#gitaly-tls-support).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The token referred to throughout the Gitaly documentation is an arbitrary
|
||||
password selected by the administrator. This token is unrelated to tokens
|
||||
created for the GitLab API or other similar web API tokens.
|
||||
|
|
@ -1298,7 +1298,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
|
|||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
Gitaly server. If you are addressing the Gitaly server by a hostname, you can
|
||||
either use the Common Name field for this, or add it as a Subject Alternative
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ When scaling GitLab, there are several factors to consider:
|
|||
- A load balancer is added in front to distribute traffic across the application nodes.
|
||||
- The application nodes connects to a shared file server and PostgreSQL and Redis services on the backend.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
Depending on your workflow, the following recommended reference architectures
|
||||
may need to be adapted accordingly. Your workload is influenced by factors
|
||||
including how active your users are, how much automation you use, mirroring,
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ The instructions make the assumption that you will be using the email address `i
|
|||
quit
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The `.` is a literal period on its own line.
|
||||
|
||||
If you receive an error after entering `rcpt to: incoming@localhost`
|
||||
|
|
@ -272,7 +272,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
quit
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The `.` is a literal period on its own line.
|
||||
|
||||
1. Check if the `incoming` user received the email:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ before the check result is visible on the project admin page. If the
|
|||
checks failed you can see their output on in the [`repocheck.log`
|
||||
file.](logs.md#repochecklog)
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
It is OFF by default because it still causes too many false alarms.
|
||||
|
||||
## Periodic checks
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ files and add the full paths of the alternative repository storage paths. In
|
|||
the example below, we add two more mount points that are named `nfs_1` and `nfs_2`
|
||||
respectively.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This example uses NFS. We do not recommend using EFS for storage as it may impact GitLab's performance. See the [relevant documentation](nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
|
||||
|
||||
**For installations from source**
|
||||
|
|
@ -89,7 +89,7 @@ This example uses NFS. We do not recommend using EFS for storage as it may impac
|
|||
|
||||
1. [Restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
We plan to replace [`gitlab_shell: repos_path` entry](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457) in `gitlab.yml` with `repositories: storages`. If you
|
||||
are upgrading from a version prior to 8.10, make sure to add the configuration
|
||||
as described in the step above. After you make the changes and confirm they are
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Anything discussed below is expected to be part of that folder.
|
|||
|
||||
## Hashed storage
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
In GitLab 13.0, hashed storage is enabled by default and the legacy storage is
|
||||
deprecated. Support for legacy storage is scheduled to be removed in GitLab 14.0.
|
||||
If you haven't migrated yet, check the
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ configuration:
|
|||
- GitLab 13.0 and earlier, this is set in `gitlab-shell/config.yml`.
|
||||
- GitLab 13.1 and later, this is set in `gitaly/config.toml` under the `[hooks]` section.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
The `custom_hooks_dir` value in `gitlab-shell/config.yml` is still honored in GitLab 13.1 and later
|
||||
if the value in `gitaly/config.toml` is blank or non-existent.
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ Pre-receive and post-receive server hooks can also access the following Git envi
|
|||
| `GIT_PUSH_OPTION_COUNT` | Number of push options. See [Git `pre-receive` documentation](https://git-scm.com/docs/githooks#pre-receive). |
|
||||
| `GIT_PUSH_OPTION_<i>` | Value of push options where `i` is from `0` to `GIT_PUSH_OPTION_COUNT - 1`. See [Git `pre-receive` documentation](https://git-scm.com/docs/githooks#pre-receive). |
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
While other environment variables can be passed to server hooks, your application should not rely on
|
||||
them as they can change.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ files must be provided:
|
|||
Optionally, you can also provide a bundle of CA certs (PEM-encoded) to be
|
||||
included on each signature. This will typically be an intermediate CA.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Be mindful of the access levels for your private keys and visibility to
|
||||
third parties.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ These locations can be configured using the options described below.
|
|||
|
||||
## Using local storage
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This is the default configuration
|
||||
|
||||
To change the location where Terraform state files are stored locally, follow the steps
|
||||
|
|
@ -91,7 +91,7 @@ See [the available connection settings for different providers](object_storage.m
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
|
||||
|
||||
```ruby
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
|
|||
|
||||
For Omnibus installations, run `gitlab-rake time:zones:all`.
|
||||
|
||||
NOTE: **Note:**
|
||||
NOTE:
|
||||
This Rake task does not list timezones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
|
||||
|
||||
## Changing time zone in Omnibus installations
|
||||
|
|
|
|||
|
|
@ -14,13 +14,13 @@ having an issue with GitLab, it is highly recommended that you check your
|
|||
[support options](https://about.gitlab.com/support/) first, before attempting to use
|
||||
this information.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Please note that some of these scripts could be damaging if not run correctly,
|
||||
or under the right conditions. We highly recommend running them under the
|
||||
guidance of a Support Engineer, or running them in a test environment with a
|
||||
backup of the instance ready to be restored, just in case.
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
Please also note that as GitLab changes, changes to the code are inevitable,
|
||||
and so some scripts may not work as they once used to. These are not kept
|
||||
up-to-date as these scripts/commands were added as they were found/needed. As
|
||||
|
|
@ -308,7 +308,7 @@ pp p.statistics # compare with earlier values
|
|||
|
||||
### Recreate
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
This is a destructive operation, the Wiki will be empty.
|
||||
|
||||
A Projects Wiki can be recreated by this command:
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This section includes relevant screenshots of the following example configuratio
|
|||
- [Azure Active Directory](#azure-active-directory)
|
||||
- [OneLogin](#onelogin)
|
||||
|
||||
CAUTION: **Caution:**
|
||||
WARNING:
|
||||
These screenshots are updated only as needed by GitLab Support. They are **not** official documentation.
|
||||
|
||||
If you are currently having an issue with GitLab, you may want to check your [support options](https://about.gitlab.com/support/).
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue