Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
01ef10900a
commit
32e53ae7d7
|
|
@ -3,7 +3,7 @@ import { __ } from '~/locale';
|
|||
import axios from './lib/utils/axios_utils';
|
||||
import { joinPaths } from './lib/utils/url_utility';
|
||||
|
||||
const DEFAULT_PER_PAGE = 20;
|
||||
export const DEFAULT_PER_PAGE = 20;
|
||||
|
||||
/**
|
||||
* Slow deprecation Notice: Please rather use for new calls
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
export const DEFAULT_PER_PAGE = 20;
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
import { DEFAULT_PER_PAGE } from '~/api';
|
||||
import axios from '../lib/utils/axios_utils';
|
||||
import { buildApiUrl } from './api_utils';
|
||||
import { DEFAULT_PER_PAGE } from './constants';
|
||||
|
||||
const GROUPS_PATH = '/api/:version/groups.json';
|
||||
const DESCENDANT_GROUPS_PATH = '/api/:version/groups/:id/descendant_groups';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
import { DEFAULT_PER_PAGE } from '~/api';
|
||||
import axios from '../lib/utils/axios_utils';
|
||||
import { buildApiUrl } from './api_utils';
|
||||
import { DEFAULT_PER_PAGE } from './constants';
|
||||
|
||||
const PROJECTS_PATH = '/api/:version/projects.json';
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
import { DEFAULT_PER_PAGE } from '~/api';
|
||||
import createFlash from '~/flash';
|
||||
import { __ } from '~/locale';
|
||||
import axios from '../lib/utils/axios_utils';
|
||||
import { buildApiUrl } from './api_utils';
|
||||
import { DEFAULT_PER_PAGE } from './constants';
|
||||
|
||||
const USER_COUNTS_PATH = '/api/:version/user_counts';
|
||||
const USERS_PATH = '/api/:version/users.json';
|
||||
|
|
|
|||
|
|
@ -107,8 +107,8 @@ export function formatIssueInput(issueInput, boardConfig) {
|
|||
const { labels, assigneeId, milestoneId } = boardConfig;
|
||||
|
||||
return {
|
||||
milestoneId: milestoneId ? fullMilestoneId(milestoneId) : null,
|
||||
...issueInput,
|
||||
milestoneId: milestoneId ? fullMilestoneId(milestoneId) : null,
|
||||
labelIds: [...labelIds, ...(labels?.map((l) => fullLabelId(l)) || [])],
|
||||
assigneeIds: [...assigneeIds, ...(assigneeId ? [fullUserId(assigneeId)] : [])],
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
<script>
|
||||
import ProjectAvatarDefault from '~/vue_shared/components/deprecated_project_avatar/default.vue';
|
||||
import ProjectAvatar from '~/vue_shared/components/project_avatar.vue';
|
||||
|
||||
export default {
|
||||
components: {
|
||||
ProjectAvatarDefault,
|
||||
ProjectAvatar,
|
||||
},
|
||||
props: {
|
||||
project: {
|
||||
|
|
@ -16,8 +16,12 @@ export default {
|
|||
|
||||
<template>
|
||||
<div class="context-header ide-context-header">
|
||||
<a :href="project.web_url" :title="s__('IDE|Go to project')">
|
||||
<project-avatar-default :project="project" :size="48" />
|
||||
<a :href="project.web_url" :title="s__('IDE|Go to project')" data-testid="go-to-project-link">
|
||||
<project-avatar
|
||||
:project-name="project.name"
|
||||
:project-avatar-url="project.avatar_url"
|
||||
:size="48"
|
||||
/>
|
||||
<span class="ide-sidebar-project-title">
|
||||
<span class="sidebar-context-title"> {{ project.name }} </span>
|
||||
<span
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# This module enables a record to be valid if any field is present
|
||||
#
|
||||
# Overwrite one_of_required_fields to set one of which fields must be present
|
||||
module AnyFieldValidation
|
||||
extend ActiveSupport::Concern
|
||||
|
||||
included do
|
||||
validate :any_field_present
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def any_field_present
|
||||
return unless one_of_required_fields.all? { |field| self[field].blank? }
|
||||
|
||||
errors.add(:base, _("At least one field of %{one_of_required_fields} must be present") %
|
||||
{ one_of_required_fields: one_of_required_fields })
|
||||
end
|
||||
|
||||
def one_of_required_fields
|
||||
raise NotImplementedError
|
||||
end
|
||||
end
|
||||
|
|
@ -3,14 +3,13 @@
|
|||
|
||||
%fieldset
|
||||
.form-group
|
||||
= f.label :mirror_available, _('Enable mirror configuration'), class: 'label-bold'
|
||||
= f.label :mirror_available, _('Repository mirroring configuration'), class: 'label-bold'
|
||||
.form-check
|
||||
= f.check_box :mirror_available, class: 'form-check-input'
|
||||
= f.label :mirror_available, class: 'form-check-label' do
|
||||
= _('Allow repository mirroring to be configured by project maintainers')
|
||||
= _('Allow project maintainers to configure repository mirroring')
|
||||
%span.form-text.text-muted
|
||||
= _('If disabled, only admins will be able to configure repository mirroring.')
|
||||
= link_to sprite_icon('question-o'), help_page_path('user/project/repository/repository_mirroring.md')
|
||||
= _('If disabled, only administrators can configure repository mirroring.')
|
||||
|
||||
= render_if_exists 'admin/application_settings/mirror_settings', form: f
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@
|
|||
= expanded_by_default? ? 'Collapse' : 'Expand'
|
||||
%p
|
||||
= _('Configure repository mirroring.')
|
||||
= link_to s_('Learn more.'), help_page_path('user/project/repository/repository_mirroring.md'), target: '_blank', rel: 'noopener noreferrer'
|
||||
.settings-content
|
||||
= render partial: 'repository_mirrors_form'
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
def has_matching_story?(file)
|
||||
File.file?(file.dup.sub!(/\.vue$/, '.stories.js'))
|
||||
end
|
||||
|
||||
def get_vue_shared_files(files)
|
||||
files.select do |file|
|
||||
file.end_with?('.vue') &&
|
||||
file.include?('vue_shared/') &&
|
||||
!has_matching_story?(file)
|
||||
end
|
||||
end
|
||||
|
||||
vue_shared_candidates = get_vue_shared_files(helper.all_changed_files)
|
||||
|
||||
return if vue_shared_candidates.empty?
|
||||
|
||||
documentation_url = 'https://docs.gitlab.com/ce/development/fe_guide/storybook'
|
||||
file_list = "- #{vue_shared_candidates.map { |path| "`#{path}`" }.join("\n- ")}"
|
||||
|
||||
warn "This merge request changed undocumented Vue components in `vue_shared/`. Please consider [creating Stories](#{documentation_url}) for these components:\n#{file_list}"
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class CreateVulnerabilityFindingEvidenceAssets < ActiveRecord::Migration[6.1]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
create_table_with_constraints :vulnerability_finding_evidence_assets do |t|
|
||||
t.timestamps_with_timezone null: false
|
||||
|
||||
t.references :vulnerability_finding_evidence, index: { name: 'finding_evidence_assets_on_finding_evidence_id' }, null: false, foreign_key: { on_delete: :cascade }
|
||||
t.text :type
|
||||
t.text :name
|
||||
t.text :url
|
||||
|
||||
t.text_limit :type, 2048
|
||||
t.text_limit :name, 2048
|
||||
t.text_limit :url, 2048
|
||||
end
|
||||
end
|
||||
|
||||
def down
|
||||
with_lock_retries do
|
||||
drop_table :vulnerability_finding_evidence_assets
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
ee8576a7dec8e0657a3976422f74202e3f89c9a72aae64f0f75398d0c6ff5b97
|
||||
|
|
@ -19132,6 +19132,28 @@ CREATE SEQUENCE vulnerability_feedback_id_seq
|
|||
|
||||
ALTER SEQUENCE vulnerability_feedback_id_seq OWNED BY vulnerability_feedback.id;
|
||||
|
||||
CREATE TABLE vulnerability_finding_evidence_assets (
|
||||
id bigint NOT NULL,
|
||||
created_at timestamp with time zone NOT NULL,
|
||||
updated_at timestamp with time zone NOT NULL,
|
||||
vulnerability_finding_evidence_id bigint NOT NULL,
|
||||
type text,
|
||||
name text,
|
||||
url text,
|
||||
CONSTRAINT check_5adf5d69de CHECK ((char_length(type) <= 2048)),
|
||||
CONSTRAINT check_839f29d7ca CHECK ((char_length(name) <= 2048)),
|
||||
CONSTRAINT check_9272d912c0 CHECK ((char_length(url) <= 2048))
|
||||
);
|
||||
|
||||
CREATE SEQUENCE vulnerability_finding_evidence_assets_id_seq
|
||||
START WITH 1
|
||||
INCREMENT BY 1
|
||||
NO MINVALUE
|
||||
NO MAXVALUE
|
||||
CACHE 1;
|
||||
|
||||
ALTER SEQUENCE vulnerability_finding_evidence_assets_id_seq OWNED BY vulnerability_finding_evidence_assets.id;
|
||||
|
||||
CREATE TABLE vulnerability_finding_evidence_headers (
|
||||
id bigint NOT NULL,
|
||||
created_at timestamp with time zone NOT NULL,
|
||||
|
|
@ -20568,6 +20590,8 @@ ALTER TABLE ONLY vulnerability_external_issue_links ALTER COLUMN id SET DEFAULT
|
|||
|
||||
ALTER TABLE ONLY vulnerability_feedback ALTER COLUMN id SET DEFAULT nextval('vulnerability_feedback_id_seq'::regclass);
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_assets ALTER COLUMN id SET DEFAULT nextval('vulnerability_finding_evidence_assets_id_seq'::regclass);
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_headers ALTER COLUMN id SET DEFAULT nextval('vulnerability_finding_evidence_headers_id_seq'::regclass);
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_requests ALTER COLUMN id SET DEFAULT nextval('vulnerability_finding_evidence_requests_id_seq'::regclass);
|
||||
|
|
@ -22286,6 +22310,9 @@ ALTER TABLE ONLY vulnerability_external_issue_links
|
|||
ALTER TABLE ONLY vulnerability_feedback
|
||||
ADD CONSTRAINT vulnerability_feedback_pkey PRIMARY KEY (id);
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_assets
|
||||
ADD CONSTRAINT vulnerability_finding_evidence_assets_pkey PRIMARY KEY (id);
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_headers
|
||||
ADD CONSTRAINT vulnerability_finding_evidence_headers_pkey PRIMARY KEY (id);
|
||||
|
||||
|
|
@ -22538,6 +22565,8 @@ CREATE UNIQUE INDEX epic_user_mentions_on_epic_id_and_note_id_index ON epic_user
|
|||
|
||||
CREATE UNIQUE INDEX epic_user_mentions_on_epic_id_index ON epic_user_mentions USING btree (epic_id) WHERE (note_id IS NULL);
|
||||
|
||||
CREATE INDEX finding_evidence_assets_on_finding_evidence_id ON vulnerability_finding_evidence_assets USING btree (vulnerability_finding_evidence_id);
|
||||
|
||||
CREATE INDEX finding_evidence_header_on_finding_evidence_request_id ON vulnerability_finding_evidence_headers USING btree (vulnerability_finding_evidence_request_id);
|
||||
|
||||
CREATE INDEX finding_evidence_header_on_finding_evidence_response_id ON vulnerability_finding_evidence_headers USING btree (vulnerability_finding_evidence_response_id);
|
||||
|
|
@ -27190,6 +27219,9 @@ ALTER TABLE ONLY prometheus_alerts
|
|||
ALTER TABLE ONLY term_agreements
|
||||
ADD CONSTRAINT fk_rails_6ea6520e4a FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
|
||||
|
||||
ALTER TABLE ONLY vulnerability_finding_evidence_assets
|
||||
ADD CONSTRAINT fk_rails_6edbbecba4 FOREIGN KEY (vulnerability_finding_evidence_id) REFERENCES vulnerability_finding_evidences(id) ON DELETE CASCADE;
|
||||
|
||||
ALTER TABLE ONLY project_compliance_framework_settings
|
||||
ADD CONSTRAINT fk_rails_6f5294f16c FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
|
||||
|
||||
|
|
|
|||
|
|
@ -196,9 +196,9 @@ keys must be manually replicated to the **secondary** node.
|
|||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. On the top bar, select **Menu >** **{admin}** **Admin**.
|
||||
1. On the top bar of the primary node, select **Menu >** **{admin}** **Admin**.
|
||||
1. On the left sidebar, select **Geo > Nodes**.
|
||||
1. Select **New node**.
|
||||
1. Select **Add site**.
|
||||
|
||||
1. Fill in **Name** with the `gitlab_rails['geo_node_name']` in
|
||||
`/etc/gitlab/gitlab.rb`. These values must always match *exactly*, character
|
||||
|
|
|
|||
|
|
@ -0,0 +1,291 @@
|
|||
---
|
||||
stage:
|
||||
group:
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Get started administering GitLab **(FREE)**
|
||||
|
||||
Get started with GitLab administration. Configure your organization and its authentication, then secure, monitor,
|
||||
and back up GitLab.
|
||||
|
||||
## Authentication
|
||||
|
||||
Authentication is the first step in making your installation secure.
|
||||
|
||||
- [Enforce two-factor authentication (2FA) for all users](../security/two_factor_authentication.md). We highly recommended 2FA for self-managed instances.
|
||||
- Ensure users do the following:
|
||||
- Choose a strong, secure password. If possible, store it in a password management system.
|
||||
- If it is not configured for everyone, enable [two-factor authentication (2FA)](../user/profile/account/two_factor_authentication.md) for your account.
|
||||
This one-time secret code is an additional safeguard that keeps intruders out, even if they have your password.
|
||||
- Add a backup email. If you lose access to your account, the GitLab Support team can help you more quickly.
|
||||
- Save or print your recovery codes. If you can't access your authentication device, you can use these recovery codes to sign in to your GitLab account.
|
||||
- Add [an SSH key](../ssh/index.md) to your profile. You can generate new recovery codes as needed with SSH.
|
||||
- Enable [personal access tokens](../user/profile/personal_access_tokens.md). When using 2FA, you can use these tokens to access the GitLab API.
|
||||
|
||||
## Projects and groups
|
||||
|
||||
Organize your environment by configuring your groups and projects.
|
||||
|
||||
- [Projects](../user/project/working_with_projects.md): Designate a home for your files and code or track and organize issues in a business category.
|
||||
- [Groups](../user/group/index.md): Organize a collection of users or projects. Use these groups to quickly assign people and projects.
|
||||
- [Roles](../user/permissions.md): Define user access and visibility for your projects and groups.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
Watch an overview of [groups and projects](https://www.youtube.com/watch?v=cqb2m41At6s).
|
||||
|
||||
Get started:
|
||||
|
||||
- Create a [project](../user/project/working_with_projects.md#create-a-project).
|
||||
- Create a [group](../user/group/index.md#create-a-group).
|
||||
- [Add members](../user/group/index.md#add-users-to-a-group) to the group.
|
||||
- Create a [subgroup](../user/group/subgroups/index.md#creating-a-subgroup).
|
||||
- [Add members](../user/group/subgroups/index.md#membership) to the subgroup.
|
||||
- Enable [external authorization control](../user/admin_area/settings/external_authorization.md#configuration).
|
||||
|
||||
**More resources**
|
||||
|
||||
- Learn more about [running multiple Agile teams](https://www.youtube.com/watch?v=VR2r1TJCDew).
|
||||
- Sync group memberships [by using LDAP](../administration/auth/ldap/index.md#group-sync).
|
||||
- Manage user access with inherited permissions. Use up to 20 levels of subgroups to organize both teams and projects.
|
||||
- Learn more about [inherited permissions](../user/project/members/index.md#inherited-membership).
|
||||
- View [nested category examples](../user/group/subgroups/index.md#overview).
|
||||
|
||||
## Import projects
|
||||
|
||||
You may need to import projects from external sources like GitHub, Bitbucket, or another instance of GitLab. Many external sources can be imported into GitLab.
|
||||
|
||||
- Review the [GitLab projects documentation](../user/project/index.md#project-integrations).
|
||||
- Consider [repository mirroring](../user/project/repository/repository_mirroring.md)—an [alternative to project migrations](../ci/ci_cd_for_external_repos/index.md).
|
||||
- Check out our [migration index](../user/project/import/index.md) for documentation on common migration paths.
|
||||
- Schedule your project exports with our [import/export API](../api/project_import_export.md#schedule-an-export).
|
||||
|
||||
### Popular project imports
|
||||
|
||||
- [GitHub Enterprise to self-managed GitLab](../integration/github.md#enabling-github-oauth): Enabling OAuth makes it easier for developers to find and import their projects.
|
||||
- [Bitbucket Server](../user/project/import/bitbucket_server.md#limitations): There are certain data limitations.
|
||||
For assistance with these data types, contact your GitLab account manager or GitLab Support about our professional migration services.
|
||||
|
||||
## GitLab instance security
|
||||
|
||||
Security is an important part of the onboarding process. Securing your instance protects your work and your organization.
|
||||
|
||||
While this isn't an exhaustive list, following these steps gives you a solid start for securing your instance.
|
||||
|
||||
- Use a long root password, stored in a vault.
|
||||
- Install trusted SSL certificate and establish a process for renewal and revocation.
|
||||
- [Configure SSH key restrictions](../security/ssh_keys_restrictions.md#restrict-allowed-ssh-key-technologies-and-minimum-length) per your organization's guidelines.
|
||||
- [Disable new sign-ups](../user/admin_area/settings/sign_up_restrictions.md#disable-new-sign-ups).
|
||||
- Require email confirmation.
|
||||
- Set password length limit, configure SSO or SAML user management.
|
||||
- Limit email domains if allowing sign-up.
|
||||
- Require two-factor authentication (2FA).
|
||||
- [Disable password authentication](../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled) for Git over HTTPS.
|
||||
- Set up [email notification for unknown sign-ins](../user/admin_area/settings/sign_in_restrictions.md#email-notification-for-unknown-sign-ins).
|
||||
- Configure [user and IP rate limits](https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/#user-and-ip-rate-limits).
|
||||
- Limit [webhooks local access](https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/#webhooks).
|
||||
- Set [rate limits for protected paths](../user/admin_area/settings/protected_paths.md).
|
||||
|
||||
## Monitor GitLab performance
|
||||
|
||||
After you've established your basic setup, you're ready to review the GitLab monitoring services. Prometheus is our core performance monitoring tool.
|
||||
Unlike other monitoring solutions (for example, Zabbix or New Relic), Prometheus is tightly integrated with GitLab and has extensive community support.
|
||||
|
||||
- [Prometheus](../administration/monitoring/prometheus/index.md) captures
|
||||
[these GitLab metrics](../administration/monitoring/prometheus/gitlab_metrics.md#metrics-available).
|
||||
- Learn more about GitLab [bundled software metrics](../administration/monitoring/prometheus/index.md#bundled-software-metrics).
|
||||
- Prometheus and its exporters are on by default. However, you need to [configure the service](../administration/monitoring/prometheus/index.md#configuring-prometheus).
|
||||
- Learn more about [GitLab architecture](../development/architecture.md).
|
||||
- Find out why [application performance metrics](https://about.gitlab.com/blog/2020/05/07/working-with-performance-metrics/) matter.
|
||||
- Create a [self-monitoring project](../administration/monitoring/gitlab_self_monitoring_project/index.md) to track the health of your instance.
|
||||
- Integrate Grafana to [build visual dashboards](https://youtu.be/f4R7s0An1qE) based on performance metrics.
|
||||
|
||||
### Components of monitoring
|
||||
|
||||
- [Web servers](../administration/monitoring/prometheus/gitlab_metrics.md#puma-metrics): Handles server requests and facilitates other back-end service transactions.
|
||||
Monitor CPU, memory, and network IO traffic to track the health of this node.
|
||||
- [Workhorse](../administration/monitoring/prometheus/gitlab_metrics.md#metrics-available): Alleviates web traffic congestion from the main server.
|
||||
Monitor latency spikes to track the health of this node.
|
||||
- [Sidekiq](../administration/monitoring/prometheus/gitlab_metrics.md#sidekiq-metrics): Handles background operations that allow GitLab to run smoothly.
|
||||
Monitor for long, unprocessed task queues to track the health of this node.
|
||||
|
||||
## Back up your GitLab data
|
||||
|
||||
GitLab provides backup methods to keep your data safe and recoverable. Whether you use a self-managed or a GitLab SaaS database, it's crucial to back up your data regularly.
|
||||
|
||||
- Decide on a backup strategy.
|
||||
- Consider writing a cron job to make daily backups.
|
||||
- Separately backup the configuration files.
|
||||
- Decide what should be left out of the backup.
|
||||
- Decide where to upload the backups.
|
||||
- Limit backup lifetime.
|
||||
- Run a test backup and restore.
|
||||
- Set up a way to periodically verify the backups.
|
||||
|
||||
### Back up a GitLab self-managed instance
|
||||
|
||||
The routine differs, depending on whether you deployed with Omnibus or the Helm chart.
|
||||
|
||||
When you backing up an Omnibus (single node) GitLab server, you can use a single Rake task.
|
||||
|
||||
Learn about [backing up Omnibus or Helm variations](../raketasks/backup_restore.md#back-up-gitlab).
|
||||
This process backs up your entire instance, but does not back up the configuration files. Ensure those are backed up separately.
|
||||
Keep your configuration files and backup archives in a separate location to ensure the encryption keys are not kept with the encrypted data.
|
||||
|
||||
#### Restore a backup
|
||||
|
||||
You can restore a backup only to **the exact same version and type** (Community Edition/Enterprise Edition) of GitLab on which it was created.
|
||||
|
||||
- Review the [Omnibus backup and restore documentation](https://docs.gitlab.com/omnibus/settings/backups).
|
||||
- Review the [Helm Chart backup and restore documentation](https://docs.gitlab.com/charts/backup-restore).
|
||||
|
||||
### Back up GitLab SaaS
|
||||
|
||||
Backups of GitLab databases and filesystems are taken every 24 hours, and are kept for two weeks on a rolling schedule. All backups are encrypted.
|
||||
|
||||
- GitLab SaaS creates backups to ensure your data is secure, but you can't use these methods to export or back up your data yourself.
|
||||
- Issues are stored in the database. They can't be stored in Git itself.
|
||||
- You can use the project export option in:
|
||||
- [The UI](../user/project/settings/import_export.md#exporting-a-project-and-its-data).
|
||||
- [The API](../api/project_import_export.md#schedule-an-export).
|
||||
- [Group export](../user/group/settings/import_export.md) does *not* export the projects in it, but does export:
|
||||
- Epics
|
||||
- Milestones
|
||||
- Boards
|
||||
- Labels
|
||||
- Additional items
|
||||
|
||||
For more information about GitLab SaaS backups, see our [Backup FAQ page](https://about.gitlab.com/handbook/engineering/infrastructure/faq/#gitlabcom-backups).
|
||||
|
||||
### Alternative backup strategies
|
||||
|
||||
In some situations the Rake task for backups may not be the most optimal solution. Here are some
|
||||
[alternatives](../raketasks/backup_restore.md) to consider if the Rake task does not work for you.
|
||||
|
||||
#### Option 1: File system snapshot
|
||||
|
||||
If your GitLab server contains a lot of Git repository data, you may find the GitLab backup script to be too slow. It can be especially slow when backing up to an offsite location.
|
||||
|
||||
Slowness typically starts at a Git repository data size of around 200 GB. In this case, you might consider using file system snapshots as part of your backup strategy.
|
||||
For example, consider a GitLab server with the following components:
|
||||
|
||||
- Using Omnibus GitLab
|
||||
- Hosted on AWS with an EBS drive containing an ext4 file system mounted at `/var/opt/gitlab`.
|
||||
|
||||
The EC2 instance meets the requirements for an application data backup by taking an EBS snapshot. The backup includes all repositories, uploads, and PostgreSQL data.
|
||||
|
||||
In general, if you're running GitLab on a virtualized server, you can create VM snapshots of the entire GitLab server.
|
||||
It is common for a VM snapshot to require you to power down the server.
|
||||
|
||||
#### Option 2: GitLab Geo
|
||||
|
||||
Geo provides local, read-only instances of your GitLab instances.
|
||||
|
||||
While GitLab Geo helps remote teams work more efficiently by using a local GitLab node, it can also be used as a disaster recovery solution.
|
||||
Learn more about using [Geo as a disaster recovery solution](../administration/geo/disaster_recovery/index.md).
|
||||
|
||||
Geo replicates your database, your Git repositories, and a few other assets.
|
||||
Learn more about [replication limitations](../administration/geo/replication/datatypes.md#limitations-on-replicationverification).
|
||||
|
||||
## Support for GitLab self-managed
|
||||
|
||||
GitLab provides support for self-managed GitLab through different channels.
|
||||
|
||||
- Priority support: Premium and Ultimate self-managed customers receive priority support with tiered response times.
|
||||
Learn more about [upgrading to priority support](https://about.gitlab.com/support/#upgrading-to-priority-support).
|
||||
- Live upgrade assistance: Get one-on-one expert guidance during a production upgrade. With your **priority support plan**,
|
||||
you're eligible for a live, scheduled screen-sharing session with a member of our support team.
|
||||
|
||||
To get assistance for self-managed GitLab:
|
||||
|
||||
- Use the GitLab documentation for self-service support.
|
||||
- Join the [GitLab Forum](https://forum.gitlab.com/) for community support.
|
||||
- Gather [your subscription information](https://about.gitlab.com/support/#for-self-managed-users) before submitting a ticket.
|
||||
- [Submit a support ticket](https://support.gitlab.com/hc/en-us/requests/new).
|
||||
|
||||
## Support for GitLab SaaS
|
||||
|
||||
If you use GitLab SaaS, you have several channels with which to get support and find answers.
|
||||
|
||||
- Priority support: Gold and Silver GitLab SaaS customers receive priority support with tiered response times.
|
||||
Learn more about [upgrading to priority support](https://about.gitlab.com/support/#upgrading-to-priority-support).
|
||||
- GitLab SaaS 24/7 monitoring: Our full team of site reliability and production engineers is always on.
|
||||
Often, by the time you notice an issue, someone's already looking into it.
|
||||
|
||||
To get assistance for GitLab SaaS:
|
||||
|
||||
- Access [GitLab Docs](../README.md) for self-service support.
|
||||
- Join the [GitLab Forum](https://forum.gitlab.com/) for community support.
|
||||
- Gather [your subscription information](https://about.gitlab.com/support/#for-self-managed-users) before submitting a ticket.
|
||||
- Submit a support ticket for:
|
||||
- [General assistance](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=334447)
|
||||
- [Account or sign-in issues](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000803379)
|
||||
- Subscribe to [the status page](https://status.gitlab.com/) for the latest on GitLab performance or service interruptions.
|
||||
|
||||
## API and rate limits for self-managed GitLab
|
||||
|
||||
Rate limits prevent denial-of-service or brute-force attacks. In most cases, you can reduce the load on your application
|
||||
and infrastructure by limiting the rate of requests from a single IP address.
|
||||
|
||||
Rate limits also improve the security of your application.
|
||||
|
||||
### Configure rate limits for self-managed GitLab
|
||||
|
||||
You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#admin-area-settings).
|
||||
|
||||
- Define [issues rate limits](../user/admin_area/settings/rate_limit_on_issues_creation.md) to set a maximum number of issue creation requests per minute, per user.
|
||||
- Enforce [user and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md) for unauthenticated web requests.
|
||||
- Review the [rate limit on raw endpoints](../user/admin_area/settings/rate_limits_on_raw_endpoints.md). The default setting is 300 requests per minute for raw file access.
|
||||
- Review the [import/export rate limits](../user/admin_area/settings/import_export_rate_limits.md) of the six active defaults.
|
||||
|
||||
For more information about API and rate limits, see our [API page](../api/index.md).
|
||||
|
||||
## API and rate limits for GitLab SaaS
|
||||
|
||||
Rate limits prevent denial-of-service or brute-force attacks. IP blocks usually happen when GitLab.com receives unusual traffic
|
||||
from a single IP address. The system views unusual traffic as potentially malicious based on rate limit settings.
|
||||
|
||||
Rate limits also improve the security of your application.
|
||||
|
||||
### Configure rate limits for GitLab SaaS
|
||||
|
||||
You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#admin-area-settings).
|
||||
|
||||
- Review the rate limit page.
|
||||
- Read our [API page](../api/index.md) for more information about API and rate limiting.
|
||||
|
||||
### GitLab SaaS-specific block and error responses
|
||||
|
||||
- [403 forbidden error](../user/gitlab_com/index.md#gitlabcom-specific-rate-limits): If the error occurs for all GitLab SaaS requests, look for an automated process that could have triggered a block. For more assistance, contact GitLab support with your error details, including the affected IP address.
|
||||
- [HAProxy API throttle](../user/gitlab_com/index.md#haproxy): GitLab SaaS responds with HTTP status code 429 to API requests that exceed 10 requests per second, per IP address.
|
||||
- [Protected paths throttle](../user/gitlab_com/index.md#protected-paths-throttle): GitLab SaaS responds with HTTP status code 429 to POST requests at protected paths that exceed 10 requests per minute, per IP address.
|
||||
- [Git and container registry failed authentication ban](../user/gitlab_com/index.md#git-and-container-registry-failed-authentication-ban): GitLab SaaS responds with HTTP status code 403 for one hour if it receives 30 failed authentication requests in three minutes from a single IP address.
|
||||
|
||||
## GitLab training resources
|
||||
|
||||
You can learn more about how to administer GitLab.
|
||||
|
||||
- Get involved in the [GitLab Forum](https://forum.gitlab.com/) to trade tips with our talented community.
|
||||
- Check out [our blog](https://about.gitlab.com/blog/) for ongoing updates on:
|
||||
- Releases
|
||||
- Applications
|
||||
- Contributions
|
||||
- News
|
||||
- Events
|
||||
|
||||
### Paid GitLab training
|
||||
|
||||
- GitLab education services: Learn more about [GitLab and DevOps best practices](https://about.gitlab.com/services/education/) through our specialized training courses. See our full course catalog.
|
||||
- GitLab technical certifications: Explore our [certification options](https://about.gitlab.com/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/) that focus on key GitLab and DevOps skills.
|
||||
|
||||
### Free GitLab training
|
||||
|
||||
- GitLab basics: Discover self-service guides on [Git and GitLab basics](../gitlab-basics/index.md).
|
||||
- GitLab Learn: Learn new GitLab skills in a structured course at [GitLab Learn](https://about.gitlab.com/learn/).
|
||||
|
||||
### Third-party training
|
||||
|
||||
- Udemy: For a more affordable, guided training option, consider
|
||||
[GitLab CI: Pipelines, CI/CD, and DevOps for Beginners](https://www.udemy.com/course/gitlab-ci-pipelines-ci-cd-and-devops-for-beginners/) on Udemy.
|
||||
- LinkedIn Learning: Check out [Continuous Delivery with GitLab](https://www.linkedin.com/learning/continuous-delivery-with-gitlab) on LinkedIn Learning
|
||||
for another low-cost, guided training option.
|
||||
|
|
@ -67,7 +67,7 @@ GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
|
|||
## Show GitLab license information **(PREMIUM SELF)**
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20501) in GitLab 12.6.
|
||||
> - [Moved](../../subscriptions/bronze_starter.md) to GitLab Premium in 13.9.
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
|
||||
This command shows information about your [GitLab license](../../user/admin_area/license.md) and
|
||||
how many seats are used. It is only available on GitLab Enterprise
|
||||
|
|
|
|||
|
|
@ -2368,9 +2368,9 @@ the following other supporting services are supported: NGINX, Task Runner, Migra
|
|||
Prometheus and Grafana.
|
||||
|
||||
Hybrid installations leverage the benefits of both cloud native and traditional
|
||||
Kubernetes, you can reap certain cloud native workload management benefits while
|
||||
the others are deployed in compute VMs with Omnibus as described above in this
|
||||
page.
|
||||
compute deployments. With this, _stateless_ components can benefit from cloud native
|
||||
workload management benefits while _stateful_ components are deployed in compute VMs
|
||||
with Omnibus to benefit from increased permanence.
|
||||
|
||||
NOTE:
|
||||
This is an **advanced** setup. Running services in Kubernetes is well known
|
||||
|
|
|
|||
|
|
@ -2380,9 +2380,9 @@ the following other supporting services are supported: NGINX, Task Runner, Migra
|
|||
Prometheus and Grafana.
|
||||
|
||||
Hybrid installations leverage the benefits of both cloud native and traditional
|
||||
Kubernetes, you can reap certain cloud native workload management benefits while
|
||||
the others are deployed in compute VMs with Omnibus as described above in this
|
||||
page.
|
||||
compute deployments. With this, _stateless_ components can benefit from cloud native
|
||||
workload management benefits while _stateful_ components are deployed in compute VMs
|
||||
with Omnibus to benefit from increased permanence.
|
||||
|
||||
NOTE:
|
||||
This is an **advanced** setup. Running services in Kubernetes is well known
|
||||
|
|
|
|||
|
|
@ -2391,9 +2391,9 @@ the following other supporting services are supported: NGINX, Task Runner, Migra
|
|||
Prometheus and Grafana.
|
||||
|
||||
Hybrid installations leverage the benefits of both cloud native and traditional
|
||||
Kubernetes, you can reap certain cloud native workload management benefits while
|
||||
the others are deployed in compute VMs with Omnibus as described above in this
|
||||
page.
|
||||
compute deployments. With this, _stateless_ components can benefit from cloud native
|
||||
workload management benefits while _stateful_ components are deployed in compute VMs
|
||||
with Omnibus to benefit from increased permanence.
|
||||
|
||||
NOTE:
|
||||
This is an **advanced** setup. Running services in Kubernetes is well known
|
||||
|
|
|
|||
|
|
@ -60,10 +60,7 @@ together {
|
|||
collections "**Sidekiq** x4" as sidekiq #ff8dd1
|
||||
}
|
||||
|
||||
together {
|
||||
card "**Prometheus + Grafana**" as monitor #7FFFD4
|
||||
collections "**Consul** x3" as consul #e76a9b
|
||||
}
|
||||
card "**Prometheus + Grafana**" as monitor #7FFFD4
|
||||
|
||||
card "Gitaly Cluster" as gitaly_cluster {
|
||||
collections "**Praefect** x3" as praefect #FF8C00
|
||||
|
|
@ -83,14 +80,15 @@ card "Database" as database {
|
|||
postgres_primary .[#4EA7FF]> postgres_secondary
|
||||
}
|
||||
|
||||
card "redis" as redis {
|
||||
collections "**Redis Persistent** x3" as redis_persistent #FF6347
|
||||
collections "**Redis Cache** x3" as redis_cache #FF6347
|
||||
collections "**Redis Persistent Sentinel** x3" as redis_persistent_sentinel #FF6347
|
||||
collections "**Redis Cache Sentinel** x3"as redis_cache_sentinel #FF6347
|
||||
node "**Consul + Sentinel** x3" as consul_sentinel {
|
||||
component Consul as consul #e76a9b
|
||||
component Sentinel as sentinel #e6e727
|
||||
}
|
||||
|
||||
redis_persistent <.[#FF6347]- redis_persistent_sentinel
|
||||
redis_cache <.[#FF6347]- redis_cache_sentinel
|
||||
card "Redis" as redis {
|
||||
collections "**Redis** x3" as redis_nodes #FF6347
|
||||
|
||||
redis_nodes <.[#FF6347]- sentinel
|
||||
}
|
||||
|
||||
cloud "**Object Storage**" as object_storage #white
|
||||
|
|
@ -2064,6 +2062,185 @@ Read:
|
|||
- The [Gitaly and NFS deprecation notice](../gitaly/index.md#nfs-deprecation-notice).
|
||||
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
|
||||
|
||||
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
|
||||
|
||||
As an alternative approach, you can also run select components of GitLab as Cloud Native
|
||||
in Kubernetes via our official [Helm Charts](https://docs.gitlab.com/charts/).
|
||||
In this setup, we support running the equivalent of GitLab Rails and Sidekiq nodes
|
||||
in a Kubernetes cluster, named Webservice and Sidekiq respectively. In addition,
|
||||
the following other supporting services are supported: NGINX, Task Runner, Migrations,
|
||||
Prometheus and Grafana.
|
||||
|
||||
Hybrid installations leverage the benefits of both cloud native and traditional
|
||||
compute deployments. With this, _stateless_ components can benefit from cloud native
|
||||
workload management benefits while _stateful_ components are deployed in compute VMs
|
||||
with Omnibus to benefit from increased permanence.
|
||||
|
||||
NOTE:
|
||||
This is an **advanced** setup. Running services in Kubernetes is well known
|
||||
to be complex. **This setup is only recommended** if you have strong working
|
||||
knowledge and experience in Kubernetes. The rest of this
|
||||
section will assume this.
|
||||
|
||||
### Cluster topology
|
||||
|
||||
The following tables and diagram details the hybrid environment using the same formats
|
||||
as the normal environment above.
|
||||
|
||||
First starting with the components that run in Kubernetes. The recommendations at this
|
||||
time use Google Cloud’s Kubernetes Engine (GKE) and associated machine types, but the memory
|
||||
and CPU requirements should translate to most other providers. We hope to update this in the
|
||||
future with further specific cloud provider details.
|
||||
|
||||
| Service | Nodes(1) | Configuration | GCP | Allocatable CPUs and Memory |
|
||||
|-------------------------------------------------------|----------|-------------------------|------------------|-----------------------------|
|
||||
| Webservice | 5 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | 79.5 vCPU, 62 GB memory |
|
||||
| Sidekiq | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | 11.8 vCPU, 38.9 GB memory |
|
||||
| Supporting services such as NGINX, Prometheus, etc. | 2 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | 3.9 vCPU, 11.8 GB memory |
|
||||
|
||||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Nodes configuration is shown as it is forced to ensure pod vcpu / memory ratios and avoid scaling during **performance testing**.
|
||||
In production deployments there is no need to assign pods to nodes. A minimum of three nodes in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
|
||||
<!-- markdownlint-enable MD029 -->
|
||||
|
||||
Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
|
||||
services where applicable):
|
||||
|
||||
| Service | Nodes | Configuration | GCP |
|
||||
|--------------------------------------------|-------|-------------------------|------------------|
|
||||
| Redis(2) | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` |
|
||||
| Consul(1) + Sentinel(2) | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` |
|
||||
| PostgreSQL(1) | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` |
|
||||
| PgBouncer(1) | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` |
|
||||
| Internal load balancing node(3) | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` |
|
||||
| Gitaly | 3 | 8 vCPU, 30 GB memory | `n1-standard-8` |
|
||||
| Praefect | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` |
|
||||
| Praefect PostgreSQL(1) | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` |
|
||||
| Object storage(4) | n/a | n/a | n/a |
|
||||
|
||||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. Google Cloud SQL and AWS RDS are known to work, however Azure Database for PostgreSQL is [not recommended](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61) due to performance issues. Consul is primarily used for PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However it is also used optionally by Prometheus for Omnibus auto host discovery.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. Google Memorystore and AWS Elasticache are known to work.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). AWS ELB is known to work.
|
||||
4. Should be run on reputable third party object storage (storage PaaS) for cloud implementations. Google Cloud Storage and AWS S3 are known to work.
|
||||
<!-- markdownlint-enable MD029 -->
|
||||
|
||||
NOTE:
|
||||
For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices.
|
||||
|
||||
```plantuml
|
||||
@startuml 5k
|
||||
|
||||
card "Kubernetes via Helm Charts" as kubernetes {
|
||||
card "**External Load Balancer**" as elb #6a9be7
|
||||
|
||||
together {
|
||||
collections "**Webservice** x5" as gitlab #32CD32
|
||||
collections "**Sidekiq** x3" as sidekiq #ff8dd1
|
||||
}
|
||||
|
||||
card "**Prometheus + Grafana**" as monitor #7FFFD4
|
||||
card "**Supporting Services**" as support
|
||||
}
|
||||
|
||||
card "**Internal Load Balancer**" as ilb #9370DB
|
||||
|
||||
node "**Consul + Sentinel** x3" as consul_sentinel {
|
||||
component Consul as consul #e76a9b
|
||||
component Sentinel as sentinel #e6e727
|
||||
}
|
||||
|
||||
card "Gitaly Cluster" as gitaly_cluster {
|
||||
collections "**Praefect** x3" as praefect #FF8C00
|
||||
collections "**Gitaly** x3" as gitaly #FF8C00
|
||||
card "**Praefect PostgreSQL***\n//Non fault-tolerant//" as praefect_postgres #FF8C00
|
||||
|
||||
praefect -[#FF8C00]-> gitaly
|
||||
praefect -[#FF8C00]> praefect_postgres
|
||||
}
|
||||
|
||||
card "Database" as database {
|
||||
collections "**PGBouncer** x3" as pgbouncer #4EA7FF
|
||||
card "**PostgreSQL** (Primary)" as postgres_primary #4EA7FF
|
||||
collections "**PostgreSQL** (Secondary) x2" as postgres_secondary #4EA7FF
|
||||
|
||||
pgbouncer -[#4EA7FF]-> postgres_primary
|
||||
postgres_primary .[#4EA7FF]> postgres_secondary
|
||||
}
|
||||
|
||||
card "Redis" as redis {
|
||||
collections "**Redis** x3" as redis_nodes #FF6347
|
||||
|
||||
redis_nodes <.[#FF6347]- sentinel
|
||||
}
|
||||
|
||||
cloud "**Object Storage**" as object_storage #white
|
||||
|
||||
elb -[#6a9be7]-> gitlab
|
||||
elb -[#6a9be7]-> monitor
|
||||
elb -[hidden]-> support
|
||||
|
||||
gitlab -[#32CD32]> sidekiq
|
||||
gitlab -[#32CD32]--> ilb
|
||||
gitlab -[#32CD32]-> object_storage
|
||||
gitlab -[#32CD32]---> redis
|
||||
gitlab -[hidden]--> consul
|
||||
|
||||
sidekiq -[#ff8dd1]--> ilb
|
||||
sidekiq -[#ff8dd1]-> object_storage
|
||||
sidekiq -[#ff8dd1]---> redis
|
||||
sidekiq -[hidden]--> consul
|
||||
|
||||
ilb -[#9370DB]-> gitaly_cluster
|
||||
ilb -[#9370DB]-> database
|
||||
|
||||
consul .[#e76a9b]-> database
|
||||
consul .[#e76a9b]-> gitaly_cluster
|
||||
consul .[#e76a9b,norank]--> redis
|
||||
|
||||
monitor .[#7FFFD4]> consul
|
||||
monitor .[#7FFFD4]-> database
|
||||
monitor .[#7FFFD4]-> gitaly_cluster
|
||||
monitor .[#7FFFD4,norank]--> redis
|
||||
monitor .[#7FFFD4]> ilb
|
||||
monitor .[#7FFFD4,norank]u--> elb
|
||||
|
||||
@enduml
|
||||
```
|
||||
|
||||
### Resource usage settings
|
||||
|
||||
The following formulas help when calculating how many pods may be deployed within resource constraints.
|
||||
The [5k reference architecture example values file](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/5k.yaml)
|
||||
documents how to apply the calculated configuration to the Helm Chart.
|
||||
|
||||
#### Webservice
|
||||
|
||||
Webservice pods typically need about 1 vCPU and 1.25 GB of memory _per worker_.
|
||||
Each Webservice pod will consume roughly 4 vCPUs and 5 GB of memory using
|
||||
the [recommended topology](#cluster-topology) because four worker processes
|
||||
are created by default and each pod has other small processes running.
|
||||
|
||||
For 5k users we recommend a total Puma worker count of around 40.
|
||||
With the [provided recommendations](#cluster-topology) this allows the deployment of up to 10
|
||||
Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using
|
||||
the ratio of 1 vCPU to 1.25 GB of memory _per each worker process_ for each additional
|
||||
Webservice pod.
|
||||
|
||||
For further information on resource usage, see the [Webservice resources](https://docs.gitlab.com/charts/charts/gitlab/webservice/#resources).
|
||||
|
||||
#### Sidekiq
|
||||
|
||||
Sidekiq pods should generally have 1 vCPU and 2 GB of memory.
|
||||
|
||||
[The provided starting point](#cluster-topology) allows the deployment of up to
|
||||
8 Sidekiq pods. Expand available resources using the 1 vCPU to 2GB memory
|
||||
ratio for each additional pod.
|
||||
|
||||
For further information on resource usage, see the [Sidekiq resources](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/#resources).
|
||||
|
||||
<div align="right">
|
||||
<a type="button" class="btn btn-default" href="#setup-components">
|
||||
Back to setup components <i class="fa fa-angle-double-up" aria-hidden="true"></i>
|
||||
|
|
|
|||
|
|
@ -71,6 +71,7 @@ The following reference architectures are available:
|
|||
|
||||
The following Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes, are available:
|
||||
|
||||
- [Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative)
|
||||
- [Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative)
|
||||
- [Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative)
|
||||
- [Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ type: reference, api
|
|||
|
||||
# Project remote mirrors API **(FREE)**
|
||||
|
||||
[Push mirrors](../user/project/repository/repository_mirroring.md#pushing-to-a-remote-repository)
|
||||
[Push mirrors](../user/project/repository/repository_mirroring.md#push-to-a-remote-repository)
|
||||
defined on a project's repository settings are called "remote mirrors", and the
|
||||
state of these mirrors can be queried and modified via the remote mirror API
|
||||
outlined below.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
|
|||
|
||||
|
||||
|
||||
GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository).
|
||||
GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository).
|
||||
|
||||
1. In GitLab create a
|
||||
[Personal Access Token](../../user/profile/personal_access_tokens.md)
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ repositories:
|
|||
GitLab:
|
||||
|
||||
1. Imports the project.
|
||||
1. Enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
|
||||
1. Enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository)
|
||||
1. Enables [GitHub project integration](../../user/project/integrations/github.md)
|
||||
1. Creates a web hook on GitHub to notify GitLab of new commits.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ A typical pipeline might consist of four stages, executed in the following order
|
|||
- A `production` stage, with a job called `deploy-to-prod`.
|
||||
|
||||
NOTE:
|
||||
If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
|
||||
If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository),
|
||||
you may need to enable pipeline triggering in your project's
|
||||
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
<!-- vale gitlab.Spelling = NO -->
|
||||
|
||||
In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
|
||||
on the GitLab [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
|
||||
on the GitLab [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository)
|
||||
to share his domain specific knowledge with anyone who may work in this part of the
|
||||
codebase in the future. You can find the <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [recording on YouTube](https://www.youtube.com/watch?v=sSZq0fpdY-Y),
|
||||
and the slides in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf).
|
||||
|
|
|
|||
|
|
@ -89,14 +89,14 @@ the tiers are no longer mentioned in GitLab documentation:
|
|||
- Repositories:
|
||||
- [Repository size limit](../user/admin_area/settings/account_and_limit_settings.md#repository-size-limit)
|
||||
- Repository mirroring:
|
||||
- [Pull mirroring](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository) outside repositories in a GitLab repository
|
||||
- [Pull mirroring](../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository) outside repositories in a GitLab repository
|
||||
- [Overwrite diverged branches](../user/project/repository/repository_mirroring.md#overwrite-diverged-branches)
|
||||
- [Trigger pipelines for mirror updates](../user/project/repository/repository_mirroring.md#trigger-pipelines-for-mirror-updates)
|
||||
- [Hard failures](../user/project/repository/repository_mirroring.md#hard-failure) when mirroring fails
|
||||
- [Trigger pull mirroring from the API](../user/project/repository/repository_mirroring.md#trigger-an-update-using-the-api)
|
||||
- [Mirror only protected branches](../user/project/repository/repository_mirroring.md#mirror-only-protected-branches)
|
||||
- [Bidirectional mirroring](../user/project/repository/repository_mirroring.md#bidirectional-mirroring)
|
||||
- [Mirroring with Perforce Helix via Git Fusion](../user/project/repository/repository_mirroring.md#mirroring-with-perforce-helix-via-git-fusion)
|
||||
- [Mirror with Perforce Helix via Git Fusion](../user/project/repository/repository_mirroring.md#mirror-with-perforce-helix-via-git-fusion)
|
||||
- Runners:
|
||||
- Run pipelines in the parent project [for merge requests from a forked project](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project)
|
||||
- [Shared runners pipeline minutes quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
stage:
|
||||
group:
|
||||
stage:
|
||||
group:
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
|
|
@ -11,13 +11,16 @@ Repository mirroring allows for the mirroring of repositories to and from extern
|
|||
can use it to mirror branches, tags, and commits between repositories. It helps you use
|
||||
a repository outside of GitLab.
|
||||
|
||||
A repository mirror at GitLab updates automatically. You can also manually trigger an update
|
||||
at most once every five minutes on GitLab.com with [the limit set by the administrator on self-managed instances](../../../administration/instance_limits.md#pull-mirroring-interval).
|
||||
A repository mirror at GitLab updates automatically. You can also manually trigger an update:
|
||||
|
||||
- At most once every five minutes on GitLab.com.
|
||||
- According to a [limit set by the administrator](../../../administration/instance_limits.md#pull-mirroring-interval)
|
||||
on self-managed instances.
|
||||
|
||||
There are two kinds of repository mirroring supported by GitLab:
|
||||
|
||||
- [Push](#pushing-to-a-remote-repository): for mirroring a GitLab repository to another location. **(FREE)**
|
||||
- [Pull](#pulling-from-a-remote-repository): for mirroring a repository from another location to GitLab. **(PREMIUM)**
|
||||
- [Push](#push-to-a-remote-repository): for mirroring a GitLab repository to another location.
|
||||
- [Pull](#pull-from-a-remote-repository): for mirroring a repository from another location to GitLab.
|
||||
|
||||
When the mirror repository is updated, all new branches, tags, and commits are visible in the
|
||||
project's activity feed.
|
||||
|
|
@ -48,9 +51,9 @@ The following are some possible use cases for repository mirroring:
|
|||
GitLab.com repository that's public, allows you to open source specific projects and contribute back
|
||||
to the open source community.
|
||||
|
||||
## Pushing to a remote repository **(FREE)**
|
||||
## Push to a remote repository
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40137) in GitLab 13.5: LFS support over HTTPS.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40137) in GitLab 13.5: LFS support over HTTPS.
|
||||
|
||||
For an existing project, you can set up push mirroring as follows:
|
||||
|
||||
|
|
@ -63,8 +66,6 @@ For an existing project, you can set up push mirroring as follows:
|
|||
1. Select the **Keep divergent refs** check box, if desired.
|
||||
1. Select **Mirror repository** to save the configuration.
|
||||
|
||||
|
||||
|
||||
When push mirroring is enabled, only push commits directly to the mirrored repository to prevent the
|
||||
mirror diverging.
|
||||
|
||||
|
|
@ -72,7 +73,7 @@ Unlike [pull mirroring](#how-it-works), the mirrored repository is not periodica
|
|||
The mirrored repository receives all changes only when:
|
||||
|
||||
- Commits are pushed to GitLab.
|
||||
- A [forced update](#forcing-an-update) is initiated.
|
||||
- A [forced update](#force-an-update) is initiated.
|
||||
|
||||
Changes pushed to files in the repository are automatically pushed to the remote mirror at least:
|
||||
|
||||
|
|
@ -82,14 +83,14 @@ Changes pushed to files in the repository are automatically pushed to the remote
|
|||
In the case of a diverged branch, an error displays in the **Mirroring repositories**
|
||||
section.
|
||||
|
||||
### Configuring push mirrors through the API
|
||||
### Configure push mirrors through the API
|
||||
|
||||
You can also create and modify project push mirrors through the
|
||||
[remote mirrors API](../../../api/remote_mirrors.md).
|
||||
|
||||
### Keep divergent refs
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208828) in GitLab 13.0.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208828) in GitLab 13.0.
|
||||
|
||||
By default, if any ref on the remote mirror has diverged from the local
|
||||
repository, the *entire push* fails, and no updates occur.
|
||||
|
|
@ -108,7 +109,7 @@ update.
|
|||
NOTE:
|
||||
After the mirror is created, this option can only be modified via the [API](../../../api/remote_mirrors.md).
|
||||
|
||||
### Setting up a push mirror from GitLab to GitHub
|
||||
### Set up a push mirror from GitLab to GitHub
|
||||
|
||||
To set up a mirror from GitLab to GitHub, you need to follow these steps:
|
||||
|
||||
|
|
@ -121,7 +122,7 @@ The mirrored repository is listed. For example, `https://*****:*****@github.com/
|
|||
|
||||
The repository pushes shortly thereafter. To force a push, select the **Update now** (**{retry}**) button.
|
||||
|
||||
### Setting up a push mirror from GitLab to AWS CodeCommit
|
||||
### Set up a push mirror from GitLab to AWS CodeCommit
|
||||
|
||||
AWS CodeCommit push mirroring is the best way to connect GitLab repositories to
|
||||
AWS CodePipeline, as GitLab isn't yet supported as one of their Source Code Management (SCM) providers.
|
||||
|
|
@ -203,7 +204,7 @@ To test mirroring by forcing a push, select the half-circle arrows button (hover
|
|||
If **Last successful update** shows a date, you have configured mirroring correctly.
|
||||
If it isn't working correctly, a red `error` tag appears and shows the error message as hover text.
|
||||
|
||||
### Setting up a push mirror to another GitLab instance with 2FA activated
|
||||
### Set up a push mirror to another GitLab instance with 2FA activated
|
||||
|
||||
1. On the destination GitLab instance, create a [personal access token](../../profile/personal_access_tokens.md) with `write_repository` scope.
|
||||
1. On the source GitLab instance:
|
||||
|
|
@ -211,7 +212,7 @@ If it isn't working correctly, a red `error` tag appears and shows the error mes
|
|||
1. Fill in the **Password** field with the GitLab personal access token created on the destination GitLab instance.
|
||||
1. Select **Mirror repository**.
|
||||
|
||||
## Pulling from a remote repository **(PREMIUM)**
|
||||
## Pull from a remote repository **(PREMIUM)**
|
||||
|
||||
> - [Added Git LFS support](https://gitlab.com/gitlab-org/gitlab/-/issues/10871) in GitLab 11.11.
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
|
|
@ -238,18 +239,12 @@ mirror pulling:
|
|||
- **Only mirror protected branches**
|
||||
1. Select **Mirror repository** to save the configuration.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
Because GitLab is now set to pull changes from the upstream repository, you should not push commits
|
||||
directly to the repository on GitLab. Instead, any commits should be pushed to the remote repository.
|
||||
Changes pushed to the remote repository are pulled into the GitLab repository, either:
|
||||
|
||||
- Automatically in a certain period of time.
|
||||
- When a [forced update](#forcing-an-update) is initiated.
|
||||
- When a [forced update](#force-an-update) is initiated.
|
||||
|
||||
WARNING:
|
||||
If you do manually update a branch in the GitLab repository, the branch becomes diverged from
|
||||
|
|
@ -273,7 +268,7 @@ Repository mirrors are updated as Sidekiq becomes available to process them. If
|
|||
|
||||
### Overwrite diverged branches **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
You can choose to always update your local branches with remote versions, even if they have
|
||||
diverged from the remote.
|
||||
|
|
@ -285,7 +280,7 @@ To use this option, check the **Overwrite diverged branches** box when creating
|
|||
|
||||
### Trigger pipelines for mirror updates **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
If this option is enabled, pipelines trigger when branches or tags are
|
||||
updated from the remote repository. Depending on the activity of the remote
|
||||
|
|
@ -295,7 +290,7 @@ assigned when you set up pull mirroring.
|
|||
|
||||
### Hard failure **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
After 14 consecutive unsuccessful retries, the mirroring process is marked as a hard failure
|
||||
and mirroring attempts stop. This failure is visible in either the:
|
||||
|
|
@ -303,11 +298,11 @@ and mirroring attempts stop. This failure is visible in either the:
|
|||
- Project's main dashboard.
|
||||
- Pull mirror settings page.
|
||||
|
||||
You can resume the project mirroring again by [forcing an update](#forcing-an-update).
|
||||
You can resume the project mirroring again by [forcing an update](#force-an-update).
|
||||
|
||||
### Trigger an update using the API **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
Pull mirroring uses polling to detect new branches and commits added upstream, often minutes
|
||||
afterwards. If you notify GitLab by [API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
|
||||
|
|
@ -317,7 +312,7 @@ For more information, see [Start the pull mirroring process for a Project](../..
|
|||
|
||||
## Mirror only protected branches **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
Based on the mirror direction that you choose, you can opt to mirror only the
|
||||
[protected branches](../protected_branches.md) in the mirroring project,
|
||||
|
|
@ -329,7 +324,7 @@ creating a repository mirror. **(PREMIUM)**
|
|||
|
||||
## SSH authentication
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22982) in GitLab 11.6 for Push mirroring.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22982) in GitLab 11.6 for Push mirroring.
|
||||
|
||||
SSH authentication is mutual:
|
||||
|
||||
|
|
@ -418,7 +413,7 @@ NOTE:
|
|||
The generated keys are stored in the GitLab database, not in the file system. Therefore,
|
||||
SSH public key authentication for mirrors cannot be used in a pre-receive hook.
|
||||
|
||||
## Forcing an update **(FREE)**
|
||||
## Force an update **(FREE)**
|
||||
|
||||
While mirrors are scheduled to update automatically, you can always force an update by using the
|
||||
update button which is available on the **Mirroring repositories** section of the **Repository Settings** page.
|
||||
|
|
@ -427,7 +422,7 @@ update button which is available on the **Mirroring repositories** section of th
|
|||
|
||||
## Bidirectional mirroring **(PREMIUM)**
|
||||
|
||||
> - Moved to GitLab Premium in 13.9.
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
WARNING:
|
||||
Bidirectional mirroring may cause conflicts.
|
||||
|
|
@ -451,13 +446,17 @@ protected branches.
|
|||
|
||||
### Configure a webhook to trigger an immediate pull to GitLab
|
||||
|
||||
Assuming you have already configured the [push](#setting-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated) and [pull](#pulling-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an immediate pull as suggested above, you must configure a [Push Event Web Hook](../integrations/webhooks.md#push-events) in the downstream instance.
|
||||
Assuming you have already configured the [push](#set-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated)
|
||||
and [pull](#pull-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an
|
||||
immediate pull as suggested above, you must configure a [Push Event Web Hook](../integrations/webhooks.md#push-events)
|
||||
in the downstream instance.
|
||||
|
||||
To do this:
|
||||
|
||||
1. Create a [personal access token](../../profile/personal_access_tokens.md) with `API` scope.
|
||||
1. In your project, go to **Settings > Webhooks**.
|
||||
1. Add the webhook URL which (in this case) uses the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project) request to trigger an immediate pull after updates to the repository.
|
||||
1. Add the webhook URL which (in this case) uses the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project)
|
||||
request to trigger an immediate pull after updates to the repository.
|
||||
|
||||
```plaintext
|
||||
https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
|
||||
|
|
@ -468,7 +467,7 @@ To do this:
|
|||
|
||||
To test the integration, select the **Test** button and confirm GitLab doesn't return an error message.
|
||||
|
||||
### Preventing conflicts using a `pre-receive` hook
|
||||
### Prevent conflicts using a pre-receive hook
|
||||
|
||||
WARNING:
|
||||
The solution proposed negatively affects the performance of
|
||||
|
|
@ -551,7 +550,7 @@ Note that this sample has a few limitations:
|
|||
- The script circumvents the Git hook quarantine environment because the update of `$TARGET_REPO`
|
||||
is seen as a ref update, and Git displays warnings about it.
|
||||
|
||||
### Mirroring with Perforce Helix via Git Fusion **(PREMIUM)**
|
||||
### Mirror with Perforce Helix via Git Fusion **(PREMIUM)**
|
||||
|
||||
> Moved to GitLab Premium in 13.9.
|
||||
|
||||
|
|
@ -584,15 +583,20 @@ Should an error occur during a push, GitLab displays an **Error** highlight for
|
|||
|
||||
### 13:Received RST_STREAM with error code 2 with GitHub
|
||||
|
||||
If you receive an "13:Received RST_STREAM with error code 2" while mirroring to a GitHub repository, your GitHub settings might be set to block pushes that expose your email address used in commits. Either set your email address on GitHub to be public, or disable the [Block command line pushes that expose my email](https://github.com/settings/emails) setting.
|
||||
If you receive a "13:Received RST_STREAM with error code 2" message while mirroring to a GitHub repository,
|
||||
your GitHub settings might be set to block pushes that expose your email address used in commits. Either
|
||||
set your email address on GitHub to be public, or disable the [Block command line pushes that expose my email](https://github.com/settings/emails) setting.
|
||||
|
||||
### 4:Deadline Exceeded
|
||||
|
||||
When upgrading to GitLab 11.11.8 or newer, a change in how usernames are represented means that you may need to update your mirroring username and password to ensure that `%40` characters are replaced with `@`.
|
||||
When upgrading to GitLab 11.11.8 or newer, a change in how usernames are represented means that you
|
||||
may need to update your mirroring username and password to ensure that `%40` characters are replaced with `@`.
|
||||
|
||||
### Connection blocked because server only allows public key authentication
|
||||
|
||||
As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a [TCP Check](../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful, you must check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.
|
||||
As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a
|
||||
[TCP Check](../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful,
|
||||
you must check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.
|
||||
|
||||
For example, we've seen this error when a Firewall was performing a `Deep SSH Inspection` on outgoing packets.
|
||||
|
||||
|
|
|
|||
|
|
@ -3363,6 +3363,9 @@ msgstr ""
|
|||
msgid "Allow owners to manually add users outside of LDAP"
|
||||
msgstr ""
|
||||
|
||||
msgid "Allow project maintainers to configure repository mirroring"
|
||||
msgstr ""
|
||||
|
||||
msgid "Allow projects and subgroups to override the group setting"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -3378,9 +3381,6 @@ msgstr ""
|
|||
msgid "Allow rendering of diagrams in AsciiDoc and Markdown documents using %{link}."
|
||||
msgstr ""
|
||||
|
||||
msgid "Allow repository mirroring to be configured by project maintainers"
|
||||
msgstr ""
|
||||
|
||||
msgid "Allow requests to the local network from hooks and services."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -4605,6 +4605,9 @@ msgstr ""
|
|||
msgid "At least one approval from a code owner is required to change files matching the respective CODEOWNER rules."
|
||||
msgstr ""
|
||||
|
||||
msgid "At least one field of %{one_of_required_fields} must be present"
|
||||
msgstr ""
|
||||
|
||||
msgid "At least one of group_id or project_id must be specified"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -12199,9 +12202,6 @@ msgstr ""
|
|||
msgid "Enable maintenance mode"
|
||||
msgstr ""
|
||||
|
||||
msgid "Enable mirror configuration"
|
||||
msgstr ""
|
||||
|
||||
msgid "Enable or disable the Pseudonymizer data collection."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -13087,6 +13087,9 @@ msgstr ""
|
|||
msgid "EscalationPolicies|IF alert is not %{alertStatus} in %{minutes} minutes"
|
||||
msgstr ""
|
||||
|
||||
msgid "EscalationPolicies|Maximum of 10 rules has been reached."
|
||||
msgstr ""
|
||||
|
||||
msgid "EscalationPolicies|Minutes must be between 0 and 1440."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -16475,7 +16478,7 @@ msgstr ""
|
|||
msgid "If disabled, a diverged local branch will not be automatically updated with commits from its remote counterpart, to prevent local data loss. If the default branch (%{default_branch}) has diverged and cannot be updated, mirroring will fail. Other diverged branches are silently ignored."
|
||||
msgstr ""
|
||||
|
||||
msgid "If disabled, only admins will be able to configure repository mirroring."
|
||||
msgid "If disabled, only administrators can configure repository mirroring."
|
||||
msgstr ""
|
||||
|
||||
msgid "If enabled, GitLab will handle Object Storage replication using Geo. %{linkStart}More information%{linkEnd}"
|
||||
|
|
@ -27782,6 +27785,9 @@ msgstr ""
|
|||
msgid "Repository mirroring"
|
||||
msgstr ""
|
||||
|
||||
msgid "Repository mirroring configuration"
|
||||
msgstr ""
|
||||
|
||||
msgid "Repository must contain at least 1 file."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,35 @@
|
|||
import { filterVariables } from '~/boards/boards_util';
|
||||
import { formatIssueInput, filterVariables } from '~/boards/boards_util';
|
||||
|
||||
describe('formatIssueInput', () => {
|
||||
it('correctly merges boardConfig into the issue', () => {
|
||||
const boardConfig = {
|
||||
labels: [
|
||||
{
|
||||
type: 'GroupLabel',
|
||||
id: 44,
|
||||
},
|
||||
],
|
||||
assigneeId: '55',
|
||||
milestoneId: 66,
|
||||
weight: 1,
|
||||
};
|
||||
|
||||
const issueInput = {
|
||||
labelIds: ['gid://gitlab/GroupLabel/5'],
|
||||
projectPath: 'gitlab-org/gitlab-test',
|
||||
id: 'gid://gitlab/Issue/11',
|
||||
};
|
||||
|
||||
const result = formatIssueInput(issueInput, boardConfig);
|
||||
expect(result).toEqual({
|
||||
projectPath: 'gitlab-org/gitlab-test',
|
||||
id: 'gid://gitlab/Issue/11',
|
||||
labelIds: ['gid://gitlab/GroupLabel/5', 'gid://gitlab/GroupLabel/44'],
|
||||
assigneeIds: ['gid://gitlab/User/55'],
|
||||
milestoneId: 'gid://gitlab/Milestone/66',
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
describe('filterVariables', () => {
|
||||
it.each([
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
import { shallowMount } from '@vue/test-utils';
|
||||
import IDEProjectHeader from '~/ide/components/ide_project_header.vue';
|
||||
import ProjectAvatar from '~/vue_shared/components/project_avatar.vue';
|
||||
|
||||
const mockProject = {
|
||||
name: 'test proj',
|
||||
avatar_url: 'https://gitlab.com',
|
||||
path_with_namespace: 'path/with-namespace',
|
||||
web_url: 'https://gitlab.com/project',
|
||||
};
|
||||
|
||||
describe('IDE project header', () => {
|
||||
let wrapper;
|
||||
|
||||
const findProjectAvatar = () => wrapper.findComponent(ProjectAvatar);
|
||||
const findProjectLink = () => wrapper.find('[data-testid="go-to-project-link"');
|
||||
|
||||
const createComponent = () => {
|
||||
wrapper = shallowMount(IDEProjectHeader, { propsData: { project: mockProject } });
|
||||
};
|
||||
|
||||
afterEach(() => {
|
||||
wrapper.destroy();
|
||||
});
|
||||
|
||||
describe('template', () => {
|
||||
beforeEach(() => {
|
||||
createComponent();
|
||||
});
|
||||
|
||||
it('renders ProjectAvatar with correct props', () => {
|
||||
expect(findProjectAvatar().props()).toMatchObject({
|
||||
projectName: mockProject.name,
|
||||
projectAvatarUrl: mockProject.avatar_url,
|
||||
});
|
||||
});
|
||||
|
||||
it('renders a link to the project URL', () => {
|
||||
const link = findProjectLink();
|
||||
expect(link.exists()).toBe(true);
|
||||
expect(link.attributes('href')).toBe(mockProject.web_url);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
|
@ -221,7 +221,7 @@ RSpec.describe Tooling::Danger::ProjectHelper do
|
|||
|
||||
describe '.local_warning_message' do
|
||||
it 'returns an informational message with rules that can run' do
|
||||
expect(described_class.local_warning_message).to eq('==> Only the following Danger rules can be run locally: changelog, database, documentation, duplicate_yarn_dependencies, eslint, gitaly, karma, pajamas, pipeline, prettier, product_intelligence, utility_css')
|
||||
expect(described_class.local_warning_message).to eq('==> Only the following Danger rules can be run locally: changelog, database, documentation, duplicate_yarn_dependencies, eslint, gitaly, karma, pajamas, pipeline, prettier, product_intelligence, utility_css, vue_shared_documentation')
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ module Tooling
|
|||
prettier
|
||||
product_intelligence
|
||||
utility_css
|
||||
vue_shared_documentation
|
||||
].freeze
|
||||
|
||||
CI_ONLY_RULES ||= %w[
|
||||
|
|
|
|||
Loading…
Reference in New Issue